💡
In a real app, we'd probably use a Cognito User Pool, or OIDC, for user-facing authentication. I used an API key for simplicity.
## The Step Functions State Machine
The second component of our application is a [Step Functions state machine](https://github.com/bboure/serverless-eda-graphql-api/blob/main/lib/state-machine-construct.ts). This state machine orchestrates the different steps of processing an order: payment, waiting for the restaurant to prepare the meal, waiting for delivery, etc.
For simplicity, I used [wait tasks](https://docs.aws.amazon.com/step-functions/latest/dg/amazon-states-language-wait-state.html) to simulate the workflow. In a real application, the state machine would wait for real processes (e.g. payment gateway), or humans (e.g. meal preparation) before transitioning between the different states (hint: probably using the [callback pattern](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token)).
The most important part is the `EventBridgePutEvents` tasks. After every step in the order processing workflow, it receives the updated order and puts an event into the event bus with all its details. In the next section, we'll see how they are being handled.
```typescript
// lib/state-machine-construct.ts
createNotifyUpdate(name: string) {
return new EventBridgePutEvents(this, `Notify ${name}`, {
entries: [
// generates an event from the task input
{
source: 'order.processing',
detailType: 'order.updated',
detail: TaskInput.fromObject({
'order.$': '$.order',
}),
eventBus: this.eventBus,
},
],
resultPath: '$.eventBridgeResult',
});
}
```
## Put It All Together
So far, we've learned about the AppSync API, and the Step Functions workflow. Did you notice that both those services place events into EventBridge? What I haven't shown you yet is how those events are used and how they play together.
In our application, the first thing that happens is a user placing an order. That's the starting point of the whole process, and it results in an `order.created` event. If you look at our [state machine construct](https://github.com/bboure/serverless-eda-graphql-api/blob/main/lib/state-machine-construct.ts), you'll notice that it subscribes to those events to start a new execution.
```typescript
new Rule(this, 'OrderHandlerRule', {
eventBus: eventBus,
eventPattern: {
// subscribe to order.created events, coming from the api.
source: ['order.api'],
detailType: ['order.created'],
},
targets: [
new SfnStateMachine(sm, {
input: RuleTargetInput.fromObject({
order: EventField.fromPath('$.detail'),
}),
}),
],
});
```
This means, that each time an order is placed, a Step Functions workflow will start with the order details as its input.
Then, as the state machine goes over all the different steps of the order processing, it emits `order.updated` events, which in turn are picked up by an EventBridge-AppSync rule.
```typescript
new CfnRule(scope, 'UpdateOrder', {
eventBusName: eventBus.eventBusName,
eventPattern: {
source: ['order.processing'],
'detail-type': ['order.updated'],
},
targets: [
{
id: 'OrderUpdated',
arn: (api.node.defaultChild as CfnGraphQLApi).attrGraphQlEndpointArn,
roleArn: ebRuleRole.roleArn,
appSyncParameters: {
graphQlOperation: `mutation NotifyOrderUpdated($input: NotifyOrderUpdatedInput!) { notifyOrderUpdated(input: $input) { id status updatedAt } }`,
},
inputTransformer: {
inputPathsMap: {
id: '$.detail.order.id',
status: '$.detail.order.status',
updatedAt: '$.detail.order.updatedAt',
},
inputTemplate: JSON.stringify({
input: {
id: '