Hey @davidcdthor
, thanks for your great comment, positive criticism about the framework is always welcome! I agree with many of your points and things like replacing our embedded auth API by support for standard JWT issuers, and composability of the cloud implementation via plugins (for instance, to use Aurora instead of DynamoDB or HTTP endpoints instead of GraphQL) are currently in our immediate roadmap. You definitely hit the nail on these concerns.
While it's true that you could easily map concepts like @Command to a @Post request or a @ReadModel with a @Get, we are firm believers that using words that are closer to the business domain, could make a difference in the way teams communicate and ease the overall development process (Nothing new here, just borrowing DDD/CQRS ideas). Most frameworks nowadays are based on MVC + ORMs, which are terms that don't really map with real-world concepts, they're developers'-only representations of the system. Booster inspiration comes from DDD, CQRS and Event-Sourcing.
To illustrate the concept for less familiar with DDD folks: The words we use matter. When someone in a meeting claims "I want to send an email to the customer every time that an order is completed", the experienced developer will immediately figure out how to map that into code no matter the implementation, but when they explain the plan, it's easier for everyone in the team to understand when you say "I'm going to create an event handler that sends the email to the customer every time that it receives an order completed event" than saying "I'll create a hook in the model that triggers a function every time an order is persisted by the ORM and the state of the order is completed that send an email to the customer". Both can be understood and explained, but the first is closer to facilitate understanding.
Making Booster easy to approach has been always a key for us. We want to allow people to learn, use, and deploy it in minutes, removing everything that we can from their way. That's why it's so opinionated, and that is by design, understanding that it won't work for a good chunk of situations (Like choosing Event-Sourcing as one of the main design pillars, which is definitely not for every problem but has some nice implications over traditional state persistence). As you said, the benefits for the cases where this specific arrangement of technologies and design work are huge, saving a ton of time and enabling people to build things that otherwise they wouldn't have time to build.
The preference for serverless also comes from this way of thinking: we want developers to start very quickly, but this is not actually a restriction. the way the code is run in the framework has been fully abstracted into provider-specific separate npm packages. Currently, the best support is for AWS, because it's the one we use more often, but there is also progress done in the Kubernetes package using Microsoft's DAPR, and nothing stops us from creating a package that uses Terraform to deploy the application to your custom setup, or why not, a package built on top of Architect.io which would benefit of its building blocks and deployment features 😉. The nicest benefit about the way it's implemented is that you can switch from one provider to another with no code changes (apart from switching the provider object in src/config/config.ts), so it could be possible to start using serverless and switch to other implementation in the future if the project succeeds the costs go crazy (vendor lock-in is always the elephant in the room regarding serverless). It's not really that you can't decide, but that we hide it from the developer if they don't need to decide.
Booster is still a very young framework. Of course, there are other fantastic frameworks out there that solve other things better. I don't think it's here to replace anything but to become a nice sidekick that boosts team productivity when implementing event-sourced highly-scalable services on the cloud as fast as possible. And you know, it's open-source, so it'll become whatever we want it to be. We have a small but welcoming community eager for ideas!
Great response! For what it's worth, I think the initial set of "opinions" I saw were solid, and I generally agree with a lot of the design decisions that have been made. I'm excited to see how the extensibility progresses!
Hey @davidcdthor , thanks for your great comment, positive criticism about the framework is always welcome! I agree with many of your points and things like replacing our embedded auth API by support for standard JWT issuers, and composability of the cloud implementation via plugins (for instance, to use Aurora instead of DynamoDB or HTTP endpoints instead of GraphQL) are currently in our immediate roadmap. You definitely hit the nail on these concerns.
While it's true that you could easily map concepts like
@Commandto a@Postrequest or a@ReadModelwith a@Get, we are firm believers that using words that are closer to the business domain, could make a difference in the way teams communicate and ease the overall development process (Nothing new here, just borrowing DDD/CQRS ideas). Most frameworks nowadays are based on MVC + ORMs, which are terms that don't really map with real-world concepts, they're developers'-only representations of the system. Booster inspiration comes from DDD, CQRS and Event-Sourcing.Making Booster easy to approach has been always a key for us. We want to allow people to learn, use, and deploy it in minutes, removing everything that we can from their way. That's why it's so opinionated, and that is by design, understanding that it won't work for a good chunk of situations (Like choosing Event-Sourcing as one of the main design pillars, which is definitely not for every problem but has some nice implications over traditional state persistence). As you said, the benefits for the cases where this specific arrangement of technologies and design work are huge, saving a ton of time and enabling people to build things that otherwise they wouldn't have time to build.
The preference for serverless also comes from this way of thinking: we want developers to start very quickly, but this is not actually a restriction. the way the code is run in the framework has been fully abstracted into provider-specific separate npm packages. Currently, the best support is for AWS, because it's the one we use more often, but there is also progress done in the Kubernetes package using Microsoft's DAPR, and nothing stops us from creating a package that uses Terraform to deploy the application to your custom setup, or why not, a package built on top of Architect.io which would benefit of its building blocks and deployment features 😉. The nicest benefit about the way it's implemented is that you can switch from one provider to another with no code changes (apart from switching the provider object in
src/config/config.ts), so it could be possible to start using serverless and switch to other implementation in the future if the project succeeds the costs go crazy (vendor lock-in is always the elephant in the room regarding serverless). It's not really that you can't decide, but that we hide it from the developer if they don't need to decide.Booster is still a very young framework. Of course, there are other fantastic frameworks out there that solve other things better. I don't think it's here to replace anything but to become a nice sidekick that boosts team productivity when implementing event-sourced highly-scalable services on the cloud as fast as possible. And you know, it's open-source, so it'll become whatever we want it to be. We have a small but welcoming community eager for ideas!
Great response! For what it's worth, I think the initial set of "opinions" I saw were solid, and I generally agree with a lot of the design decisions that have been made. I'm excited to see how the extensibility progresses!
Thanks!