Are Rails' conventions going too far?

Does the inclusion of the rails-api gem into Rails 5 kill other Rails API gems?

I personally prefer Grape and its wonderful ecosystem, but now I must consider rails-api or hope that I can continue to use Grape in the future. Is this a case of DHH’s convention-bias going too far?

What do you think?

1 Like

You are confusing two things. I am a big fan of grape myself, and I always use it in a rails context. Either using rails-api, which allows to have lighter middle-ware. Or because I have a rails-application and also want to offer an API to e.g. third parties.

The rails-api gem supports you in making the default middle-ware stack a little lighter (e.g. you do not need session management in an API call), parses json to fill up params, handles HEAD requests transparently, … This are all useful for any API.

But rails-api does not help you in building the API, if you use rails-api, you would still have to create controllers and routes for your api: exactly what grape is good at. So they are imho still a perfect match.

HA…shows you what I know. I’ve never used rails-api…but you probably guessed as much.

Would you use Grape with rails-api? Have you?

I think there will always be other options. We build APIs in Sinatra and so far it has been great, especially with Sequel and Sidekiq gems (Lotus looks very promising, too). There are some features in Rails that I think are too much and will slap you in the face (e.g. autoloading weirdness with namespaces) or are downward dangerous (instance variables in views). But then theres the whole bunch of lovely stuff like routes and form builders. :smile:

I am intrigued by Pliny, have you looked at it?

Nope, but thanks for the link. :smiley:

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.