Architecture
Architecture Diagram
Spaces
There are three places where code can run.
Userspace — user-written code. In development it runs locally; when deployed, it runs inside an AWS Lambda.
Client — code packaged in the Floww SDK. Responsible for invoking userspace with the correct context.
Server — backend code that interacts with the database, deploys AWS Lambdas, and invokes them with the correct context.
Components
| Component | Role |
|---|---|
| WorkOS | Authentication provider across CLI, admin page, dashboard, etc. |
| Centrifugo | Manages WebSocket connections and broadcasting for live flow triggers |
| CLI | Part of the SDK — provides init, dev, deploy, and other commands |
| SDK | Contains provider action implementations and typings for triggers |
| ECR | AWS container registry storing Docker runtimes used by Lambdas |
Flows
Dev (client)
Prerequisites
- Check that the workflow exists
Execution
- Fetch available providers in the namespace
- Initialize userspace with provider configs
- Execute userspace — returns triggers and provider usage
- Verify all used providers are configured (prompt user if any are missing)
- Set up event routing to userspace via WebSocket and local events
📝
Reruns
- Code changes re-run from step 3
- Configuring a provider re-runs from step 1
Deploy (client)
Prerequisites
- Check that the workflow exists (prompt user to create one if missing)
Checks
- Fetch available providers in the namespace
- Execute userspace — returns triggers and provider usage
- Verify all used providers are configured (prompt user if any are missing)
Deploy
- Build the runtime image
- Upload runtime image (if not already present)
- Create runtime (if not already present)
- Create deployment
📝
Reruns
- Configuring a provider re-runs from step 2
Incoming webhook (server)
- Receive inbound HTTP request at the webhook URL
- Look up the matching trigger registration by path
- Invoke the associated Lambda with the request payload
- Return the Lambda’s response to the caller