📄️ Environments
You can create multiple environments calling the Booster.configure function several times using different environment names as the first argument. You can create one file for each environment, but it is not required. In this example we set all environments in a single file:
📄️ The Register object
The Register object is a built-in object that is automatically injected by the framework into all command or event handlers to let users interact with the execution context. It can be used for a variety of purposes, including:
📄️ Configuring Infrastructure Providers
The providers are different implementations of the Booster runtime to allow Booster applications run on different cloud providers or services. They all implement the same interface, and the main idea behind the providers is that no matter what the developer chooses as backend, they won't need to know anything about the underlying infrastructure.
📄️ Create custom providers
Booster provides an infrastructure layer out of the box with sensible defaults that you can use for rapid development, but if
🗃️ Extending Booster with Rockets!
4 items
🗃️ Sensors
1 items
📄️ Testing
Booster applications are fully tested by default. This means that you can be sure that your application will work as expected. However, you can also write your own tests to check that your application behaves as you expect. In this section, we will leave some recommendations on how to test your Booster application.
📄️ Migrations
Learn how to migrate data in Booster
📄️ TouchEntities
Learn how to update entities and ReadModels
📄️ Customizing CLI resource templates
You can change what the newly created Booster resources will contain by customizing the resource template files.
📄️ Framework packages
The framework is already splitted into different packages:
📄️ Booster instrumentation
Trace Decorator
📄️ Scaling Booster Azure Functions
Booster Azure Provider relies on CosmosDB change feed processor to consume new events.