Introduction

⚡️ SchmeaWatcher is a CDK construct that allows you to quickly setup notifications for downstream consumers when using Amazon EventBridge.

⚡️ SchemaWatcher is a plugin-based construct. Using plugins developers can write any notification support they want. Write a new plugin, connect it to the construct and SchemaWatcher will do the rest.

⚡️ Easy of use, developer experience and event-driven governance is key to this project.

Motivation

SchemaWatcher is a CDK construct that can help you scale your event-driven architecture by allowing event consumers to subscribe to schema changes.

Amazon EventBridge is a serverless event bus that lets you receive, filter, transform, route, and deliver events, you can write custom event producers and listen to them downstream with custom rules and consumers.

Amazon EventBridge also offers a Schema Registry. EventBridge provides schemas for all events that are generated by AWS services and when you turn on schema discovery it will automatically detect and provide schemas for your custom events (OpenAPI and JSON Schemas).

When producers make changes to events or raise new events onto your EventBridge bus, EventBridge will automatically picks up these changes (with schema discovery turned on), and either make new schemas or update schemas for you.

Consumers can use these schemas to validate events, understand what is in the payload of events or even document their event-driven architecture using tools like EventCatalog.

As time goes on your event-driven architectures will grow, keeping on top of producer and consumer relationships can be hard, we are often told that “producers should not know about consumers”. Technically there is an element of truth to this, but you will often find this leads to some problems…

So, what if we could notify consumers of incoming breaking changes in our schema’s? Notifying consumers could help us manage our event-driven architectures and scale them as our organisations scale.

SchemaWatcher was designed to help developers manage their event-driven architecture. Notifying consumers of any changes to event structures can help catch issues before you see them in production.

Something missing?

If you find issues with the documentation or have suggestions on how to improve the documentation or the project in general, please file an issue.