The Async API spec is absolutely fantastic, but what if you could generate this automatically from the data already flowing through your application? If only the data flowing through your event stream could be captured and have event schema automatically generated, versioned, and recorded in a database. This talk walks you through what we’ve done with Inngest to implement this into our system and how we built a tool to generate Async API specs automatically. From inferring event schema, creating an versioned event schema registry and generating Async API specs from this data. With this auto-generated Async API spec one can then take advantage of all of the wonderful tools in the Async API ecosystem.

1. An Auto-Documenting
Event-Driven
Architecture Using
Async API and Inngest
Dan Farrelly
@djfarrelly

2. Why event schemas are important
Why automatically generate event schemas
How we automatically generate event schemas
How you can use it yourself
2
What we’ll cover
Overview

3. Founder, Inngest.com
Former CTO, Buffer.com
Event-driven architecture and home restoration enthusiast
dan@inngest.com
3
Dan Farrelly
Who am I?

4. Inngest is an event-driven platform that makes it easy for developers to
build, test, then deploy serverless functions triggered by events — without
worrying about infrastructure, queues, or stateful services.
4
What is Inngest?
Who am I?
“An event-driven architecture in a box”
Features: schema registry, logging, metrics, SDKs and tooling

5. 5
Why build event-driven?
But first,
Event-driven can be beautifully simple
You publish immutable facts & you run code based on those facts
You get flexibility with fan-out - n consumers for a single event
A highly decoupled architecture

6. What’s the most important
part of an EDA?
<Hint: it’s in the name>

7. 7
Events!
What’s the most important part of an EDA?
If events are facts, they cannot be changed
The system needs to make sure that services (read: teams) are publishing
facts correctly
To accomplish this, we need to document these facts and add
controls to our system
Enter AsyncAPI…

8. 8
How to create AsyncAPI specs?
AsyncAPI
1) Write it manually
2) Automatically parse events in real-time and self-document

9. 9
Automatically parsing events
Why write specs?
Inngest uses HTTP + JSON
Each event received is sent to a worker that parses & generates a schema
Clients can specify a new event version by using a new v field value
Every new version is stored in the registry in a meta format: CUE

10. 10
What is CUE? Why use it?
cuelang.org
Chosen for interoperability
CUE is a data validation format that can
parse, validate and generate JSON, YAML,
Open API spec (JSON Schema), and Go structs.
Our custom parser walks any JSON object,
parses the type of each field and generates
a CUE definition.

11. 11
How it works
Event API
(https://inn.gs/)
Pub/Sub
Event Recorder
Schema Registry
Schema
Validation
CUE Parser
Job Scheduler
Serverless Functions

12. 12
Inngest Schema Registry

13. 13
Self-documenting API + Async API
Match made in heaven
This enables us to fetch JSON schema right from the Inngest API and
build our Async API spec.
Ever user workspace has its own event registry, each event requires a
name and is versioned
Everything is wrapped up into a simple npm package

14. 14
Why translate to Async API?
Async API
We can tap into the Async API ecosystem
Tooling: Code generation, etc.
Documentation: Standard format for sharing system architecture
Future: Use Async API to publish to schema registry; Schema
enforcement tools

15. 15
See it in action!
npm install inngest-cli && inngest login
npx @inngest/asyncapi

16. 16
That’s it!

17. Questions?
Thanks for listening!
@djfarrelly