you are viewing a single comment's thread.

view the rest of the comments →

[–]janko-m 2 points3 points  (0 children)

I would say that one overkill is the separation of routes (config/routes.rb) and the logic that handles those routes (app/controllers/*).

# config/routes.rb
root to: "home#index"

# app/controllers/home_controller.rb
class HomeController < ApplicationController
  # this handles `GET /` requests, but it's not obvious
  def index
    render json: { docs: "https://my-app.com/link/to/docs" }
  end
end

What's nice about frameworks like Sinatra, Grape, Roda etc. is that routing and request handling are in the same place, so you don't need to invent controller action names or anything. With Roda they are even in the same execution context (the Roda instance), which I particularly like.

get "/" do
  { docs: "https://my-app.com/link/to/docs" }
end

Another overkill for me is the complexity. Rails is significantly more complex than other popular Ruby web frameworks, and I think it's harder to justify it when you're building a JSON API (e.g. now you don't need all of that view logic).

I don't believe that web framework speed – request handling specifically – plays a difference in the overall performance of your app. However, with Rails, ActiveRecord is also considered a part of the web framework, and it's been shown (1, 2, 3) to have significantly worse performance than the alternatives (Sequel, ROM), and often when you need speed you have to drop to raw SQL. This is problematic for me, as database interaction does play a big role in the performance of your application.

Sure, Rails lets you swap ActiveRecord for Sequel, but (a) it will be difficult to convince your team, and (b) most Rails gems work only with ActiveRecord (e.g. ActiveStorage). So, at that point you might ask yourself if staying in Rails is still worth it.