Hi @drbragg
, first of all, thanks for your constructive criticism and for taking the time to look into Booster; I think you hit the nail in many interesting topics where we can improve.
I used to write a lot of Rails code before switching to other things, and for me, and as it happens to you, the Rails version looks natural and 100% understandable, but after mentoring a couple of developers in their journey to Rails, I can tell you that it's easy for experts to forget the amount of knowledge packed in little things like a belongs_to or an after_create_commit.
As a major contributor of Booster, I would be extremely biased to say that the TypeScript version is "simpler", but what I can say is that the framework is still young and that the goal is to make it simpler over time. For instance, talking about the code sample you pasted, one thing we've thought is emulating Ruby's autoload to remove all these imports from the user's code. There are also plans to make projections implicit by default, as they're often just copying the data from entities. With that change, the Booster ReadModels become almost only data structures.
One thing that can surprise you at the beginning is that Booster uses a totally different architecture than Rails, as it's based on CQRS and Event-Sourcing instead of MVP, so you have to think differently about your code. In Rails, you can easily follow everything that happens when you hit a controller by just reading the code in the corresponding method. In Booster, a command only stores an event, and you can't tell what happens after the event is stored by just looking at the code. The way to do that is searching for the registered event type to see what event handlers and entities are observing it. I think that it could make a lot of sense to develop some IDE integrations that help to visualize this.
Regarding costs, the main difference between Booster and Rails is in the delivery mechanism and its price model more than the specific price or service you choose to use. I think that @j2rguez
was just sharing typical configurations here, but you can always tweak your config to build much more cost-effective solutions. Booster currently works on top of AWS Lambda and DynamoDB, which have very different price models than VPS or database instances, but in the future we're planning to support deploying Booster applications on Kubernetes clusters too, where the price model is much closer to Rails'. Indeed, the opposite can also be done, you could deploy a Rails app in AWS lambda to get the same pricing benefits using Jets Afterburner, but that's probably only for the experts and the bravest :-D
Booster is definitely a very different architecture than Rails, which is why I felt compelled to respond when Rails was used as a comparison framework. It's like comparing how effective a screwdriver is verses a hammer for putting a screw in a piece of wood. Booster is built to easily build this example where Rails is not. I would love to see it stacked against other node based frameworks or against something else in the serverless world like Go.
Booster is an extremely cool project and I'll definitely being following its development.
Thanks for your kind words, we're always looking to keep improving Booster, and conversations like this are very useful for us! If you try it, feel free to send some issues with questions, suggestions, or feature requests!
@j2rguez
is a great Rails engineer that we've been trying to "evangelize" into Booster for a while, and I can't hide that seeing him writing this article and defending Booster over his favorite framework makes me happy, but yes! Booster and Rails are very different projects that are hard to compare. Indeed a purely CRUD application is likely to look way simpler in Rails, but this is still a good exercise to understand how Booster compares to existing frameworks.
As a new framework that's trying to find its place, there's a recurrent question from devs that look at it for the first time: how does it compare to my current framework, and why should I consider switching or doing my next project in Booster?
Seeing the same application implemented in both frameworks is a good starting point to answer that question, but this example only explores one subset of everything that Rails can do, and probably not the best one. It would be interesting to see an article written with the opposite approach, starting with an app that fits well in Rails to see how Booster copes with it, I bet we'd find a lot of interesting ideas for future releases!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi @drbragg , first of all, thanks for your constructive criticism and for taking the time to look into Booster; I think you hit the nail in many interesting topics where we can improve.
I used to write a lot of Rails code before switching to other things, and for me, and as it happens to you, the Rails version looks natural and 100% understandable, but after mentoring a couple of developers in their journey to Rails, I can tell you that it's easy for experts to forget the amount of knowledge packed in little things like a
belongs_toor anafter_create_commit.As a major contributor of Booster, I would be extremely biased to say that the TypeScript version is "simpler", but what I can say is that the framework is still young and that the goal is to make it simpler over time. For instance, talking about the code sample you pasted, one thing we've thought is emulating Ruby's autoload to remove all these imports from the user's code. There are also plans to make projections implicit by default, as they're often just copying the data from entities. With that change, the Booster ReadModels become almost only data structures.
One thing that can surprise you at the beginning is that Booster uses a totally different architecture than Rails, as it's based on CQRS and Event-Sourcing instead of MVP, so you have to think differently about your code. In Rails, you can easily follow everything that happens when you hit a controller by just reading the code in the corresponding method. In Booster, a command only stores an event, and you can't tell what happens after the event is stored by just looking at the code. The way to do that is searching for the registered event type to see what event handlers and entities are observing it. I think that it could make a lot of sense to develop some IDE integrations that help to visualize this.
Regarding costs, the main difference between Booster and Rails is in the delivery mechanism and its price model more than the specific price or service you choose to use. I think that @j2rguez was just sharing typical configurations here, but you can always tweak your config to build much more cost-effective solutions. Booster currently works on top of AWS Lambda and DynamoDB, which have very different price models than VPS or database instances, but in the future we're planning to support deploying Booster applications on Kubernetes clusters too, where the price model is much closer to Rails'. Indeed, the opposite can also be done, you could deploy a Rails app in AWS lambda to get the same pricing benefits using Jets Afterburner, but that's probably only for the experts and the bravest :-D
Booster is definitely a very different architecture than Rails, which is why I felt compelled to respond when Rails was used as a comparison framework. It's like comparing how effective a screwdriver is verses a hammer for putting a screw in a piece of wood. Booster is built to easily build this example where Rails is not. I would love to see it stacked against other node based frameworks or against something else in the serverless world like Go.
Booster is an extremely cool project and I'll definitely being following its development.
Thanks for your kind words, we're always looking to keep improving Booster, and conversations like this are very useful for us! If you try it, feel free to send some issues with questions, suggestions, or feature requests!
@j2rguez is a great Rails engineer that we've been trying to "evangelize" into Booster for a while, and I can't hide that seeing him writing this article and defending Booster over his favorite framework makes me happy, but yes! Booster and Rails are very different projects that are hard to compare. Indeed a purely CRUD application is likely to look way simpler in Rails, but this is still a good exercise to understand how Booster compares to existing frameworks.
As a new framework that's trying to find its place, there's a recurrent question from devs that look at it for the first time: how does it compare to my current framework, and why should I consider switching or doing my next project in Booster?
Seeing the same application implemented in both frameworks is a good starting point to answer that question, but this example only explores one subset of everything that Rails can do, and probably not the best one. It would be interesting to see an article written with the opposite approach, starting with an app that fits well in Rails to see how Booster copes with it, I bet we'd find a lot of interesting ideas for future releases!