Booster framework vs Ruby on Rails

After all these years, Ruby on Rails is still one of the frameworks we like most. Now that we’ve developed the Booster framework, we’re curious about how it stacks up to Rails in various aspects:

• Code: How much code do you need to write to get similar features?
• Infrastructure and configuration: What resources are needed? How are they configured? How are they kept up and running in a production environment?
• Scalability and costs estimation: What if our application starts to grow? How much effort and cost will there be?

The plan for this comparison is to build a real-time chat application on both frameworks with three models: Chat Room, Messages, and Users. To save time, we’ve gone ahead and built the app with both frameworks. If you want to see the full code, go ahead and check our Ruby on Rails and Booster repos.

Code

To build the Ruby on Rails application, we chose Action Cable and Rails 6. If you’ve worked with Ruby on Rails before, you know the steps we needed to take:

1. Set up Docker using Redis as our Action Cable adapter.
2. Configure authentication.
3. Generate the models, controllers, and views for our app.

Maybe the hardest part was properly configuring the Action Cable client-server interaction. It’s challenging but can be accomplished by reading the docs carefully.

And what about Booster? Before we begin talking about the implementation, we encourage you to check out the Booster architecture documentation.

To begin with this app, we replicated the models from our Ruby on Rails application shared above, with the objective of creating at least one command, event, entity and read-model for each one. We didn’t need to install additional dependencies, and even authorization and authentication is built-in.

Although the objective of this article is not to do a tutorial, we want to show you just one use case:

When I create a chat room, the current user must exist in the system

@Command({ authorize: [User, Admin] }) 
export class CreateChatRoom { 
  public constructor( 
    readonly name: string, 
    readonly description: string, 
    readonly isPrivate: boolean) {} 

  public async handle(register: Register): Promise<void> { 
    if (register.currentUser) { 
      const userProfile = await Booster.fetchEntitySnapshot(
        UserProfile, 
        register.currentUser.email
      ) 
      if (userProfile) { 
        register.events(new ChatRoomCreated(
          UUID.generate(), 
          this.name, 
          this.description, 
          userProfile, 
          this.isPrivate
        )) 
      } else { 
        throw 'Error trying to create a chat room. User not found.' 
      } 
    }          
  }
}

As you can see, by using the Register object, you can retrieve information from the current user. It can also be used to read entities from event-handlers, so you will always have access to existing data in the system by just writing one line of code.

Infrastructure and configuration

Since the code is ready, it’s time to think about where we want to deploy these apps. For the Ruby on Rails application, we just went for the easiest option, which is Heroku.

Still, we’re missing a couple of important components for this infrastructure to be complete: Redis and PostgreSQL. In a Ruby on Rails application, we should configure the environment files (and the action cable one) to point to these services.

The Booster Framework has an AWS-based infrastructure (for now), which depends on DynamoDB, AWS Lambda, API Gateway, and AWS Cognito. Here’s a diagram just in case you’re curious about the infrastructure:

To deploy a Booster application, you just have to type boost deploy -e <environment> on your CLI, and Booster will automatically generate and connect all AWS services mentioned above for that specific environment.

Scalability and costs estimation

Another important point of comparison is cost and scalability. Let’s estimate the relative costs of a production environment for both frameworks:

Heroku production environment:

• Performance-M dyno ($250 per month, per dyno)
• 1GB Redis plan ($100 per month)
• Private 0 PostgreSQL plan ($300 per month)

This makes a total of $650 per month, and we didn’t take into account the scalability of the system. As your application starts growing, you will need to increase not just the number of dynos, but to upgrade the PostgreSQL and Redis add-ons.

In the Booster Framework, all deployed services are included in the AWS free tier. After this initial year and depending on your region, you will mostly pay for the resources that you actively use.

So, how much would it cost to create a production environment using Booster? (eu-west-1 region)

• DynamoDB: 64GB of capacity, 1 million read and writes on-demand = $220.89
• AWS Lambda: 1 million requests, 1500ms request duration, 1GB memory allocated = $25.20
• API Gateway:
  • REST API: 1 million requests = $3.50
  • Websocket API: 1 million requests = $1.14. We will also pay $0.285 per million connection minutes.
• AWS Cognito: The first 50,000 monthly active users are free even without the free tier.

These prices would end at a total cost of approximately $249.59 per month, with a maximum of 50,000 active users. Remember that this price may vary depending on your region and your monthly requests and/or data stored.

And what about scalability? The AWS services that Booster uses will scale automatically as your applications start receiving more requests, so you don’t have to worry about any additional configuration!

Conclusions

Developing with Ruby on Rails was very comfortable but the Action Cable part was not as natural and simple as we’d like it to be. Booster, on the other hand, not only has authorization built-in, but we don’t have to worry about dependencies and the code is much easier to read. It felt like we were focusing on business actions and not low-level technical configuration and boilerplate code.

Regarding infrastructure and configuration, Booster takes the lead here. Being able to deploy your entire application by running one single command without any other additional configuration is definitely a huge advantage. In the case of Ruby on Rails, configuring it on Heroku is not a very big deal but still requires you to create the app and connect Redis and PostgreSQL for every environment.

Finally, the cost of running a production environment with Booster is much cheaper than with Ruby on Rails. Furthermore, when scaling your application in Booster you don’t need to worry about any additional or special configurations. Everything is done automatically for you.

Overall based on these criteria, we think that Booster is a better choice. Still, we would be missing the benchmarking side of both apps but that’s for another article so, stay tuned!