We want to explore the possibility of running Booster apps in Docker containers as well as open the door for more flexible deployment strategies and supporting new databases. Booster <2.x.x design hides the infrastructure side of the application, making a decision on behalf of the developer on which databases to use or their configuration. This is nice for a quick start or test of the framework, but as soon as the project starts growing, it easily falls short and limits how the applications are managed or scaled. For that reason, most long-term Booster users have ended up implementing their own provider packages to be able to tweak and extend the infrastructure.
For v3.x.x, we want to explore a different approach, managing Booster applications as regular node applications, removing the infrastructure automation, and replacing the opaque provider library interface with a series of independent components. We want to explore the following changes:
Separate event store component: The event store will be an independent database we connect to with a connection string. This will allow us to write event store adapters for several databases, separate the location of the event store from the chosen runtime, and combine databases in any way we want.
Separate read models database: Similar to the event store component, the read models database will now be managed as an independent component with its own database connection string. This separation eases the use of different databases or database instances for event storage and read model management, allowing for better performance optimization tailored to the specific needs of each use case. Moreover, it opens the door to writing adapters for various databases for read models, enhancing the database support spectrum of Booster, and providing more choices to developers in aligning their database selection with project requirements and deployment strategies.
Removal of infrastructure inference: Instead, Booster will export a schema definition file that can be used to parameterize your own scripts. We may still provide default templates for quick start, but they won't be part of the code.
Runnable Booster apps with standard node scripts: With the aim to improve the ease of deployment and local development experience, we propose to construct templates for Fastify or Bun.sh servers. These templates would enable developers to effortlessly run their projects as servers either locally or within Docker containers. For deployments on serverless platforms such as AWS Lambda or Azure Functions, Booster will continue to export the key functions while supplying adapter libraries to process the specific events of these environments.
Effectively removing the local provider: Being able to run the applications on top of fastify/bun servers and being able to configure custom databases with regular connection scripts renders the local provider obsolete, so it will no longer needed.
This sets the vision for a more flexible design for the Booster framework, focusing on the things it does right as a framework: Designing event-sourcing systems, and removing the existing restrictions to run your Booster applications.
orefalo
commented
8 months ago
Spike
We want to explore the possibility of running Booster apps in Docker containers as well as open the door for more flexible deployment strategies and supporting new databases. Booster <2.x.x design hides the infrastructure side of the application, making a decision on behalf of the developer on which databases to use or their configuration. This is nice for a quick start or test of the framework, but as soon as the project starts growing, it easily falls short and limits how the applications are managed or scaled. For that reason, most long-term Booster users have ended up implementing their own provider packages to be able to tweak and extend the infrastructure.
For v3.x.x, we want to explore a different approach, managing Booster applications as regular node applications, removing the infrastructure automation, and replacing the opaque provider library interface with a series of independent components. We want to explore the following changes:
This sets the vision for a more flexible design for the Booster framework, focusing on the things it does right as a framework: Designing event-sourcing systems, and removing the existing restrictions to run your Booster applications.