Admin Web and Compatibility Services
Why the older service layer still exists and which current business journeys it supports.
The agapi-member-booking repository is not only an old frontend. It still
contains current pieces that connect staff and member actions to Agapi's data and
external services.
The obsolete browser-based member frontend under agapi/mobile is excluded from
this guide. The admin web, compatibility API, WebSocket service, uploads, and
background jobs are described because other current parts of the platform still
depend on them.
What this repository does today
| Part | Why it exists |
|---|---|
| Admin web | Gives staff the screens used to manage bookings, members, boats, messages, settings, and reports. |
| Compatibility HTTP API | Keeps established member and utility requests working while responsibilities are shared with Symfony. |
| Real-time RPC service | Gives the admin and compatibility API a common way to run many business actions and notify connected screens that data changed. |
| Scheduled work | Checks time-sensitive bookings and sends selected reminders without waiting for a person to open the portal. |
| File and media service | Uploads, retrieves, resizes, and streams images, documents, PDFs, and videos used by members and staff. |
Why “compatibility” does not mean “unused”
The code has older technology and some responsibilities overlap with Symfony, but removing it would break routes and real-time actions that still have callers. The safe way to change a feature is to follow the actual request from the screen or client and find its owner.
flowchart LR
Admin[Admin screen] --> Wrapper[Admin API wrapper]
Member[Member client] --> Http[Compatibility HTTP API]
Wrapper --> Symfony[Symfony API]
Wrapper --> Rpc[Real-time RPC service]
Http --> Rpc
Http --> Direct[Direct compatibility handler]
Rpc --> DB[(PostgreSQL)]
Direct --> DB
Symfony --> DBSome HTTP routes handle the request themselves. Some forward the action to the real-time service. Some admin actions go straight to Symfony. The route name alone is not enough to tell which path is used.
The main business journeys it supports
- staff sign-in and account-scoped admin work;
- member sign-in, password recovery, profile, and device registration;
- finding regions, locations, boats, boat types, tutorials, and contacts;
- bookings, requests, availability, prices, changes, and cancellations;
- check-in, check-out, condition questions, photos, and boat issues;
- fuel, engine hours, balances, invoices, saved cards, and subscriptions;
- SMS, push, email reminders, and delivery information;
- staff reports, shared settings, file handling, and optional integrations.
The following pages explain these journeys by purpose:
- Member-facing Compatibility API
- Real-time Actions and Shared Records
- Background Jobs, Files, and Integrations
Rules for changes
- Do not remove an older action merely because a Symfony action has a similar name; prove that all callers have moved.
- Keep account/company context and the current user token when crossing between services.
- Treat a successful first step and a failed second step as a partial operation, not as a safe full retry.
- Keep credentials out of logs and documentation, including values found in example environment files.
- Do not use the excluded
agapi/mobilefrontend as proof of current screen behavior.