Docs
Dashboard
Docs
Dashboard

Architecture

this outlines the architecture to help contributors understand what components exist and what each does

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. it’s responsible for invoking the userspace with the correct context

server: backend code that interacts with the database, deploys aws lambdas, and invokes them with the correct context

Components

in addition to the spaces, several components coordinate everything

  • workos: authentication provider across cli, admin page, dashboard, etc
  • centrifugo: manages websocket connections and broadcasting for live flow triggers
  • cli: part of the sdk that provides various commands
  • sdk: contains code for actions, plus typings for triggers and providers
  • ecr: aws registry storing docker runtimes used by lambdas
  • ecr proxy: provides fine-grained access control when pushing images to ecr

Flows

(client) dev

1. prerequisites
  1. check that the workflow exists
2. execution
  1. fetch available providers in the namespace
  2. initialize userspace with provider configs
  3. execute userspace (returns triggers and provider usage)

  4. verify all used providers are configured

    • prompt user if any are missing
  5. set up event routing to userspace (websocket + local events)
reruns
  • code changes (reloads) re-run the flow from step 3
  • setting up a provider re-runs the flow from step 1

(client) deploy

1. prerequisites

  1. check that the workflow exists

    • if not, prompt the user to create one
2. checks
  1. fetch available providers in the namespace
  2. execute userspace (returns triggers and provider usage)

  3. verify all used providers are configured

    • prompt user if any are missing
3. deploy
  1. build the runtime image
  2. upload runtime image (if missing)
  3. create runtime (if missing)
  4. create deployment
reruns
  • setting up a provider re-runs the checks flow from step 2

(server) incoming webhook

NOTE
  • setting up a provider re-runs the checks flow from step 2
ON THIS PAGE