Appearance

The Lifecycle of a Request ​

To understand how the platform's decoupled services work together, let's follow the journey of a single request: a user clicking "Save" on a new Task record. This example connects back to the one in A Developer's First Look.

Step-by-Step Breakdown ​

  1. GraphQL Mutation (Client to API) The user's action in the Platform UI is translated into a GraphQL mutation. This request, containing the new task data and the user's JWT, is sent to the single, unified GraphQL endpoint.

  2. Authentication & Authorization (API Gateway) The Data API Gateway receives the request. Before proceeding, it calls the Identity Service to validate the JWT. The Identity Service confirms the token's signature, expiry, and that the user has the necessary permissions for the operation.

  3. SQL Execution (API Gateway to Database) Once authorized, the Data API Gateway's GraphQL-to-SQL compiler transforms the mutation into an optimized and secure INSERT statement. It executes this SQL against the specific Tenant Database.

  4. Database Event (Database to Event Bus) Upon a successful INSERT, the PostgreSQL database uses its logical replication capabilities to automatically emit a change event. This event is captured and published to the NATS Event Bus, containing the new task's data.

  5. Asynchronous Processing (Event Bus to Triggers) The Trigger Service, which is always listening for events on the bus, receives the "task created" event. It consults its registry to see if any logic needs to be run in response to this event (e.g., sending a notification).

  6. Logic Execution (Triggers to Logic Runtime) If a corresponding Action is found, the Trigger Service invokes the Logic Runtime. It passes the event data as context and executes the sandboxed WASM code for the Action. This entire process is managed by our highly concurrent, fault-tolerant Elixir/OTP-based services, capable of handling millions of simultaneous events.

  7. Completion The user in the UI received an immediate success message back in Step 4. The asynchronous background processing (Steps 5 & 6) happens independently, ensuring the user experience is fast while the system's backend processes are robust and decoupled.

This event-driven flow is the key to the Simple Platform's scalability and resilience. Services can operate independently, and new functionality can be added by simply subscribing to existing event streams without modifying core services.

Next Step ​

Understand the different ways services communicate with each other and the outside world.

→ Communication Patterns