5 ms·

I love Ruby, but I have no love for Rails. Want to write a nice JSON API using something light and nice? Use Sinatra, pick your favorite ORM (even ActiveRecord)

I love Ruby, but I have no love for Rails. Want to write a nice JSON API using something light and nice? Use Sinatra, pick your favorite ORM (even ActiveRecord) and go to town. Why mess with all the other Rails junk when you can have a simple app.rb for your sinatra app and just write simple little controller actions and you're good to go? You don't need all the ceremony and structure of Rails and MVC to write a JSON api, you just don't. Worrying about Rails' future and if it's still "winning"(for some definition of winning?) compared to node.js is silly and reminds me of how many Java devs had an existential crisis about the future of Java since Java 7 took a few too many years to ship. Rails is a web MVC framework, that's it. It's not even the only or best web framework in ruby. Rails is not ruby. It is not designed to compete with node. Node is a totally different thing. Compare node and ruby and that's a more interesting and correct comparison, but I've happily used both and neither one is going to "kill" the other any more than Rails killed PHP or Java killed C++.

nahname 14y ago
I really liked using Sinatra until I used it with a team. The lack of ceremony and structure (as you put it) killed us. The app started out as just a simple service, so why not use Sinatra right? Then things changed and we were more focused on the web side, but stuck with Sinatra because everyone had heard the FUD about rails. Each person has a preference on where they thought something should be. Days were spent arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it. This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.
- joedoe55555 14y ago
  My experience is similar. Sinatra is great for one-man-shows or really simple REST apis. For the rest, forget about it... However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing. I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable. But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized. Great when building but it sucks when debugging and maintaining.
  - protobluffers 14y ago
    The more abstraction you shove down the programmer's throat, the less he will understand what's really going on behind the scenes. Eventually the abstractions become more of an impediment than a panacea, e.g. when you try to do simple things. And we also end up with the creation of "leaky abstractions", since programmers who create them have developed a love for abstraction (what might contribute to that?) but little understanding of the lower levels. There was a recent post on HN regarding /usr/local that seemed to suggest some programmers do not understand what a partition is nor should they need to become acquainted with such unimportant details. I hope I'm wrong in that interpretation. Because if true, that is just sad.
  - codenerdz 14y ago
    Do you think that a "legacy" Node(or Sinatra for that matter) app will be easier to understand than a "legacy" Rails app? Legacy is where conventions actually shine!
- heretohelp 14y ago
  I agree that the total lack of structure in Sinatra can be harmful at times, but don't blame a technology for your team problems. That's just the bad workman blaming his tools for the faults of the toolbags he works with.
jeltz 14y ago
Agreed, when you want to build an API use Sinatra, and when you want to do web MVC there is Padrino which turns Sinatra into a very competent MVC framework.
- damncabbage 14y ago
  I've used Padrino for a couple of projects now, but unfortunately it slips into "Uncanny Valley Rails" territory (particularly when it comes to the rake tasks you expect to have but turn out to be missing, eg. db:test:prepare).
- planetmcd 14y ago
  I really enjoy Sinatra and am indeed using it for REST style API hosting, but the counter argument might be all the security stuff that is built into the Rails routes/controllers. this might be a great case for a stripped down rails app as opposed to a Sinatra app.
  - jeltz 14y ago
    I thought most of the security in Rails is provided by the rack-security middleware? Or am I forgetting something which Rails provides here?
    - dcu 14y ago
      Escaping everything by default to avoid XSS attacks. that's a nice feature to have.
      - auxbuss 14y ago
        This can be done in Sinatra: http://www.sinatrarb.com/faq.html#auto_escape_html http://www.sinatrarb.com/faq.html#auto_escape_html
nateberkopec 14y ago
FTA: https://gist.github.com/1942658 https://gist.github.com/1942658 Why wouldn't you just do a 50-line Rails app instead, and slot in any other Rails niceties when you feel like you need them?
cheald 14y ago
"Rails" is a collection of libraries and conventions, just as "Sinatra + ActiveRecord" is. There's nothing inherent in it that makes it "worse" than Sinatra (which I love, by the way) for JSON APIs. Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go? You don't need all the ceremony and structure of Sinatra to write a JSON API, you just don't.
- jallmann 14y ago
  Sinatra has a lot less boilerplate than the typical Rack app.
  - cheald 14y ago
    Because it has a lot more "ceremony and structure". Sinatra is a Rack app. It hides the raw boilerplate from you just like Rails hides a lot of the boilerplate you end up putting into a Sinatra app of any significant size. There's a continuum of "more manual work" <----> "more framework", and there's no one right answer, even for something like a JSON API.
    - jallmann 14y ago
      Rails is a Rack app too. While I agree there are diminishing returns the lower in the stack you go, your original reduction is misleading. The choice between Sinatra and Rails can reasonably be debated, but there's little reason to write a JSON API in Rack unless you need control of protocol details that neither abstraction provides. Sinatra/Rails are frameworks, Rack is middleware.
- programminggeek 14y ago
  You're absolutely right, you don't need Sinatra to write a JSON API either. The more ruby devs that realize this the better. Really, just people getting out of the mindset that Rails is the be all end all of ruby is all I'm going for.
- joedoe55555 14y ago
jmonegro 14y ago
https://github.com/spastorino/rails-api https://github.com/spastorino/rails-api Problem solved.
sunkencity 14y ago
Cheez, the reason to not use Sinatra for me is that I'd have to implement all the security measures myself. Sure for a hobby project or a really simple project it might be OK. I guess it all depends on what budget you have for spending time re-implementing all the plumbing.

nahname 14y ago

I really liked using Sinatra until I used it with a team. The lack of ceremony and structure (as you put it) killed us. The app started out as just a simple service, so why not use Sinatra right? Then things changed and we were more focused on the web side, but stuck with Sinatra because everyone had heard the FUD about rails. Each person has a preference on where they thought something should be. Days were spent arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it. This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.

joedoe55555 14y ago
My experience is similar. Sinatra is great for one-man-shows or really simple REST apis. For the rest, forget about it... However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing. I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable. But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized. Great when building but it sucks when debugging and maintaining.
- protobluffers 14y ago
  The more abstraction you shove down the programmer's throat, the less he will understand what's really going on behind the scenes. Eventually the abstractions become more of an impediment than a panacea, e.g. when you try to do simple things. And we also end up with the creation of "leaky abstractions", since programmers who create them have developed a love for abstraction (what might contribute to that?) but little understanding of the lower levels. There was a recent post on HN regarding /usr/local that seemed to suggest some programmers do not understand what a partition is nor should they need to become acquainted with such unimportant details. I hope I'm wrong in that interpretation. Because if true, that is just sad.
- codenerdz 14y ago
  Do you think that a "legacy" Node(or Sinatra for that matter) app will be easier to understand than a "legacy" Rails app? Legacy is where conventions actually shine!
heretohelp 14y ago
I agree that the total lack of structure in Sinatra can be harmful at times, but don't blame a technology for your team problems. That's just the bad workman blaming his tools for the faults of the toolbags he works with.

jeltz 14y ago

Agreed, when you want to build an API use Sinatra, and when you want to do web MVC there is Padrino which turns Sinatra into a very competent MVC framework.

damncabbage 14y ago
I've used Padrino for a couple of projects now, but unfortunately it slips into "Uncanny Valley Rails" territory (particularly when it comes to the rake tasks you expect to have but turn out to be missing, eg. db:test:prepare).
planetmcd 14y ago
I really enjoy Sinatra and am indeed using it for REST style API hosting, but the counter argument might be all the security stuff that is built into the Rails routes/controllers. this might be a great case for a stripped down rails app as opposed to a Sinatra app.
- jeltz 14y ago
  I thought most of the security in Rails is provided by the rack-security middleware? Or am I forgetting something which Rails provides here?
  - dcu 14y ago
    Escaping everything by default to avoid XSS attacks. that's a nice feature to have.
    - auxbuss 14y ago
      This can be done in Sinatra: http://www.sinatrarb.com/faq.html#auto_escape_html http://www.sinatrarb.com/faq.html#auto_escape_html

nateberkopec 14y ago

FTA: https://gist.github.com/1942658 https://gist.github.com/1942658 Why wouldn't you just do a 50-line Rails app instead, and slot in any other Rails niceties when you feel like you need them?

cheald 14y ago

"Rails" is a collection of libraries and conventions, just as "Sinatra + ActiveRecord" is. There's nothing inherent in it that makes it "worse" than Sinatra (which I love, by the way) for JSON APIs. Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go? You don't need all the ceremony and structure of Sinatra to write a JSON API, you just don't.

jallmann 14y ago
Sinatra has a lot less boilerplate than the typical Rack app.
- cheald 14y ago
  Because it has a lot more "ceremony and structure". Sinatra is a Rack app. It hides the raw boilerplate from you just like Rails hides a lot of the boilerplate you end up putting into a Sinatra app of any significant size. There's a continuum of "more manual work" <----> "more framework", and there's no one right answer, even for something like a JSON API.
  - jallmann 14y ago
    Rails is a Rack app too. While I agree there are diminishing returns the lower in the stack you go, your original reduction is misleading. The choice between Sinatra and Rails can reasonably be debated, but there's little reason to write a JSON API in Rack unless you need control of protocol details that neither abstraction provides. Sinatra/Rails are frameworks, Rack is middleware.
programminggeek 14y ago
You're absolutely right, you don't need Sinatra to write a JSON API either. The more ruby devs that realize this the better. Really, just people getting out of the mindset that Rails is the be all end all of ruby is all I'm going for.
joedoe55555 14y ago

jmonegro 14y ago

https://github.com/spastorino/rails-api https://github.com/spastorino/rails-api Problem solved.

sunkencity 14y ago

Cheez, the reason to not use Sinatra for me is that I'd have to implement all the security measures myself. Sure for a hobby project or a really simple project it might be OK. I guess it all depends on what budget you have for spending time re-implementing all the plumbing.