Bindings and Connectors
A workflow that never talks to anything is easy to make deterministic and useless. Bindings are the one door through which it talks to the outside.
flow.use(binding) hands you a dependency at an explicit point in the workflow.
You declare it once with defineBinding(name, factory).
The name is not decoration — it’s what a test uses to substitute a fake for the real thing. Ask for the same binding twice in one run and you get the same instance back.
Two rules. Keep network, database, and provider calls out of code that runs during replay. And write the factory so it’s safe to call again, because the step around it may be retried.
createGraphQLBinding({ url, ...config }), from the SDK’s GraphQL entry point.
If you leave out url, it reads GRAPHQL_ENDPOINT; if that isn’t set either,
it falls back to http://localhost:4000/-/graphql.
Headers can be functions. Use that — a credential read lazily at connection time never ends up copied into workflow state, where it would be recorded in an event and stay there.
The GraphQL reference covers the schema. There is no REST or gRPC connector in 0.2.0; don’t plan around one.
A connector adapts a protocol. It is not a place to put process logic — that belongs in the workflow, where it’s recorded and replayable.
Validate what comes back at the boundary, keep the request metadata you’d want when something goes wrong, and make sure the receiving system tolerates the same request arriving twice. Errors and Retries explains why that last one isn’t optional.