Not really, you don't have to maintain a server, because the code is being executed in lambda functions (or the equivalent of your cloud provider), database management is not needed, as Booster relies on on-demand databases that autoscale. You just write your domain logic following the patterns described :)
In the frameworks you say, you still have to write routing, middlewares, adding models, rely on repositories, etc... On top of that, you still have to figure out with them how to endue scenarios, with, say 3000 requests per second, without a failure, while Booster does this out of the box.
As you say, those are still backend frameworks because they maintain somewhat high level abstractions, but Booster takes this a step further, and abstracts infrastructure and the orchestration/architecting of it for high throughput scenarios.
Case-specific requirements, like say, for example, static hosting, are handled by Booster rockets, which essentially are plugins to extend your app written in Booster. So for example, you need to host a static site, you install the rocket, and the deployment will reconfigure itself adding that static site hosting you need.
Yeah, it could be that you might need something very specific, and would need to write your own rocket, but you truly don't need to write configuration files or backend code in the 90% of the cases.
It is as misleading as saying that for webdev no one uses pointers/registers, yet there are some case-specific requirements that make people optimize their apps to that point :)
I'd really recommend you to try it, because it's very different :D
In the frameworks you say, you still have to write routing, middlewares, adding models, rely on repositories, etc...
It looks like you did all the same with the booster framework too - you just didn't use the same words. Annotations like @Command is similar to @Get() and @Post() in NestJS, the authorization keyword used in several command examples is pretty much identical to middlewares, models and entities are the same thing, and repositories are optional abstractions in many ORMs.
What this really looks like is a much more opinionated framework rather than a different one. I can only use GraphQL, only use your choice of DB (not even sure what they use by default), only use your authorization API (also not sure what powers it), and of course can only deploy to serverless platforms. Don't get me wrong, opinionated frameworks can be extremely beneficial and can help developers build things they otherwise wouldn't be able to, but if you add too many opinions it can come at a long term cost.
you still have to figure out with them how to endue scenarios, with, say 3000 requests per second, without a failure, while Booster does this out of the box.
This was a bit of a stretch since this value is from the serverless cloud platforms, not Booster itself. Just because you can deploy to more than one platform doesn't mean this value is achieved because of the framework.
Overall nice design for the framework. Even if I'm not yet sold on it being significantly different than some other frameworks, the choices to focus on commands instead of controllers, enable easy event pub/sub, and abstract data storage via entities hit the vast majority of devs needs for sure. Certainly looks easy to approach!
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!
Not really, you don't have to maintain a server, because the code is being executed in lambda functions (or the equivalent of your cloud provider), database management is not needed, as Booster relies on on-demand databases that autoscale. You just write your domain logic following the patterns described :)
In the frameworks you say, you still have to write routing, middlewares, adding models, rely on repositories, etc... On top of that, you still have to figure out with them how to endue scenarios, with, say 3000 requests per second, without a failure, while Booster does this out of the box.
As you say, those are still backend frameworks because they maintain somewhat high level abstractions, but Booster takes this a step further, and abstracts infrastructure and the orchestration/architecting of it for high throughput scenarios.
Case-specific requirements, like say, for example, static hosting, are handled by Booster rockets, which essentially are plugins to extend your app written in Booster. So for example, you need to host a static site, you install the rocket, and the deployment will reconfigure itself adding that static site hosting you need.
Yeah, it could be that you might need something very specific, and would need to write your own rocket, but you truly don't need to write configuration files or backend code in the 90% of the cases.
It is as misleading as saying that for webdev no one uses pointers/registers, yet there are some case-specific requirements that make people optimize their apps to that point :)
I'd really recommend you to try it, because it's very different :D
It looks like you did all the same with the booster framework too - you just didn't use the same words. Annotations like
@Commandis similar to@Get()and@Post()in NestJS, theauthorizationkeyword used in several command examples is pretty much identical to middlewares, models and entities are the same thing, and repositories are optional abstractions in many ORMs.What this really looks like is a much more opinionated framework rather than a different one. I can only use GraphQL, only use your choice of DB (not even sure what they use by default), only use your authorization API (also not sure what powers it), and of course can only deploy to serverless platforms. Don't get me wrong, opinionated frameworks can be extremely beneficial and can help developers build things they otherwise wouldn't be able to, but if you add too many opinions it can come at a long term cost.
This was a bit of a stretch since this value is from the serverless cloud platforms, not Booster itself. Just because you can deploy to more than one platform doesn't mean this value is achieved because of the framework.
Overall nice design for the framework. Even if I'm not yet sold on it being significantly different than some other frameworks, the choices to focus on commands instead of controllers, enable easy event pub/sub, and abstract data storage via entities hit the vast majority of devs needs for sure. Certainly looks easy to approach!
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!