A choice of gems
After years of working on Ruby on Rails projects, Sinatra projects, and other non-standard projects and libraries, Ruby developers tend to have strong preferences in their gems choices.
Here is our shortlist and why we picked those, sorted by themes. Hopefully, that will help you pick and choose a good starter set.
Style
One of our first actions when landing in a team is to look at the coding style. Setting a common language is key to having a productive team, and not having to take care of style is the key to that.
We turn to Rubocop and its style guide to have a starting point. Then we iterate with the team members until they have something they are happy about.
And we also stick flay in the mix because it's a great tool to get some concrete ideas about how similar is our code.
Web framework
We tend to go for Ruby on Rails for most use cases: web applications and API backends ... In our opinion, it strikes a good balance in many aspects with a good ORM, an excellent overall configuration for most use cases, and a flourishing ecosystem.
Yet, we also like to keep Sinatra around for the odd job. Some mini services or API backends PoC don't need much cruft. Sinatra is an excellent choice for mocking remote APIs too. Light, fast, and easily extendable with extra gems, it's a great tool.
Rails ecosystem
A lot of our work is focused on Ruby on Rails applications. So here is what we pick especially to work with Ruby on Rails.
- decorator pattern implementation: Draper or actually just SimpleDelegator (from the standard Ruby lib)
- authentication: clearance is more straightforward than Devise but still quite powerful as it's extensible. The simpler code makes it easier to dig into and extend.
- authorization: pundit. Simple, neat.
- uploads: carrierwave. Powerful, adjustable.
- payment integration: pay. Handles Stripe, Paddle, Braintree and comes with a Fake Processor to test things out. Well documented, well supported. Just very good.
- handling configuration: we recommend relying on ENV variables to adjust the software behavior instead of "RAILS_ENV" values. Thus it's normal to rely on the config gem. The config gem can help define default values for all the configurations with the automatic handling of ENV vars to overload them.
- background jobs: we go with Sidekiq at first. As we are also RabbitMQ users so we also can go with Sneakers. We can also recommend Shoryuken when in AWS ecosystems.
- sticking to the Ruby on Rails way avoids a lot of headaches. That's why things like ActiveType are great to make any class quack, like ActiveRecord classes.
Testing & co
We stick to RSpec and capybara. We find the approach of Better specs is good and recommend following it.
And if we need data, we go for Factory Bot. It's a great solution to structure test data (Active Record models or not) without losing your mind. It also plays very well with Faker.
Security, code quality
Brakeman is an excellent tool for Ruby on Rails developers and can be complemented with the bundle audit command. If the former will tell you if your code is not great (security-wise), the latter will tell you if your gems are up to date.
In general
We keep an eye on dry-rb, but it's not 100% Ruby on Rails friendly, so we can't use it everywhere.
As Rubyists, we owe a lot to Ryan Bates. One of his precious gems (beyond the railscasts) is probably letter_opener. It is a great tool to view your Ruby on Rails application's emails in the browser without sending them.
Conclusion
There are a lot of gems out there. Hopefully, this list will help you pick a place to start and then adjust depending on your findings once your application starts to be real.
Keep an eye on projects such as Awesome-Ruby. Sometimes ... there are new gold nuggets in there.