The A-POST-OL platform
A C++ server and a business-logic platform in PostgreSQL. Sign-in and permissions, the API, business processes, events, integrations, files, messages, reports and background jobs work out of the box – a project describes only its own domain.
From one server to a cluster. Ready for Kubernetes.
A C++ server, all logic in PostgreSQL
A request enters through the server and reaches the database in a single call – where the data, the permissions and the business logic live. In the other direction the database itself hands work to background services: outbound requests, email, files, reports.
AppServerAuthServerWebSocketAPIPGHTTPFileServerGatewayAPIbehind the gateway · go-platformPGFetchPGFileMessageServerTaskSchedulerReportServerThe only door: session, context, route
daemon · api · session · current · gatewaySubscriptions, a trace of every action, notifications, codes
observer · notification · notice · comment · verificationTask queues, outbound calls, exchange between nodes
notify · http · mq · replicationIn the same database: the classes, states, methods, routes, events and permissions of your domain. The project extends the platform and does not change it.
From one server to Kubernetes
Sessions, queues and routes live in PostgreSQL, so server instances are interchangeable. The same images run on one machine, on several servers and in Kubernetes – and the project's code does not change.
- IOne serverThe server, the database and everything else – in containers on one machine.
- IIEvery coreAs many worker processes as cores; background services – one each.
- IIIDatabase clusterPostgreSQL on separate servers, with automatic failover.
- IVSeveral serversInstances on different machines behind a load balancer, one database for all.
- VKubernetesInstances in pods; the orchestrator starts and updates them one at a time.
A background service runs in one instance; the others wait in reserve and take over by themselves if the leader is gone. PostgreSQL elects the leader – no external coordinator is needed.
libapostol · leader lockAn outbound request, an email, a report or a job goes to one live instance and is closed by its confirmation. A late confirmation is rejected together with its result.
db-platform · notifyAPI v2 modules connect to any instance; the routing table is shared and kept in the database.
GatewayAPIA process finishes what it has started before it exits, and a crashed one restarts by itself. Instances are updated one at a time – the system does not stop.
libapostol · process modelEverything server-side is already there
Twelve subsystems shared by every project on the platform. A project gets them on day one and does not write them again.
Sign-in and sessions
OAuth 2.0 and JWT; sign-in by password, by code and through external providers. Sessions are kept in the database and closed on the server.
Permissions in three dimensions
On the class, the method and the object. Grants and denials for users and groups, visibility by department.
Object model
Documents and reference data in a class tree: owner, state history, links, files, addresses, texts in several languages.
Behaviour as data
States, transitions, events, routes and settings are rows in tables. They change on a running system, with no rebuild.
REST API
400+ routes out of the box; a project's route is added as a row. One request – one transaction, batches included. Alongside it, API v2 for modules in any language.
Real time
Calls and subscriptions over WebSocket. A subscriber receives only what has passed its filter and its permissions.
Integrations
Webhooks are received straight into SQL. The database queues outbound HTTP calls and a service runs them in the background, with polling as a safety net.
Messages
Email, push and SMS; notifications to users and confirmation codes for email and phone.
Files
Object files, accessible under the object's own permissions; stored on disk or in S3.
Reports
A report tree, parameter forms, generation in the background and a finished document.
Journal and audit
The event journal, the API journal and a trace of every executed method. Errors come from a catalogue: a code and a text in the user's language.
One action – one transaction
Every request takes the same path. The object, its state, its history, the journal and the money change together – or not at all.
- 01nginxTLS, domain, rate limiting
- 02ServerChecks the token's signature and makes one call to the database
- One transaction
- 03SessionWho, on whose behalf, in which department, in which language, on which operating day
- 04RouteThe path is found in the routing table
- 05PermissionsOnly the objects the caller may see and change
- 06ActionA new state, events along the class tree, the journal, notifications to subscribers
- 07ResponseJSON. A refusal is a response too: a code and a text in the user's language
- 01CommitThe transaction has recorded a task; after the commit the database wakes the service
- 02ServiceExactly one executor takes the task
- 03Outside worldA payment system, email, S3, a partner's API
- 04ResultThe answer comes back to the database as a call and changes the object's state
Processes are described, not programmed
Classes, states, methods, transitions, events and permissions are rows in the platform's tables. A business process changes on a running system, with no rebuild and no stop.
Grants and denials are set for users and groups. Visibility is further limited by the department and by the area the session works in.
Running on the platform
Discuss your project
Tell me about your task – I reply within a day. A free 30-minute call and a written estimate of timeline and budget.