Booster architecture
Booster is a highly opinionated framework that provides a complete toolset to build production-ready event-driven serverless applications.
Two patterns influence the Booster's event-driven architecture: Command-Query Responsibility Segregation (CQRS) and Event Sourcing. They're complex techniques to implement from scratch with lower-level frameworks, but Booster makes them feel natural and very easy to use.
As you can see in the diagram, Booster applications consist of four main building blocks: Commands, Events, Entities, and Read Models. Commands and Read Models are the public interface of the application, while Events and Entities are private implementation details. With Booster, clients submit Commands, query the Read Models, or subscribe to them for receiving real-time updates thanks to the out of the box GraphQL API
Booster applications are event-driven and event-sourced so, the source of truth is the whole history of events. When a client submits a command, Booster wakes up and handles it throght Command Handlers. As part of the process, some Events may be registered as needed.
On the other side, the framework caches the current state by automatically reducing all the registered events into Entities. You can also react to events via Event Handlers, triggering side effect actions to certain events. Finally, Entities are not directly exposed, they are transformed or projected into ReadModels, which are exposed to the public.
In this chapter you'll walk through these concepts in detail.
📄️ Command
Commands are any action a user performs on your application. For example, RemoveItemFromCart, RatePhoto or AddCommentToPost. They express the intention of an user, and they are the main interaction mechanism of your application. They are a similar to the concept of a request on a REST API. Command issuers can also send data on a command as parameters.
📄️ Event
An event is a fact of something that has happened in your application. Every action that takes place on your application should be stored as an event. They are stored in a single collection, forming a set of immutable records of facts that contain the whole story of your application. This collection of events is commonly known as the Event Store.
📄️ Event handler
Learn how to react to events and trigger side effects in Booster by defining event handlers.
📄️ Entity
If events are the source of truth of your application, entities are the current state of your application. For example, if you have an application that allows users to create bank accounts, the events would be something like AccountCreated, MoneyDeposited, MoneyWithdrawn, etc. But the entities would be the BankAccount themselves, with the current balance, owner, etc.
📄️ Read model
A read model contains the data of your application that is exposed to the client through the GraphQL API. It's a projection of one or more entities, so you dont have to directly expose them to the client. Booster generates the GraphQL queries that allow you to fetch your read models.
📄️ Notifications
Documentation for defining notifications in the Booster Framework using the @Notification and @partitionKey decorators.
📄️ Queries
ReadModels offer read operations over reduced events. On the other hand, Queries provide a way to do custom read operations.