7 ms·

"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 (wh

by 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
You cannot really compare Sinatra with Rails. Rails has scaffolding, DB migrations and all this ultra-highlevel stuff rendering debugging to pure guess-work. Reminds me of doing template-metaprogramming with C++. If it works it's great and the performance rocks, if not you are left alone with cryptic errors and nobody can help you.
- jeltz 14y ago
  If you want Sinatra with scaffolding there is Padrino which I personally find to have superior scaffolding compared to rails.
ajsharp 14y ago
Whole-heartedly disagree. You can't even parse a json-encoded POST body with plain-vanilla Rack without a middleware from rack-contrib HEAD (the "stable" version is about a year behind the last time I checked). Rack is a standard and abstraction for build ruby app servers and frameworks. To say it's sufficient for building production quality API's is just absurd. One of the main benefits of using frameworks like Sinatra and Rails is that you often don't need to re-write and re-implement all the same boilerplate code (like parsing JSON post bodies) over and over again. And the difference with rails and sinatra vs most other open source projects is the size and activity community, and as a result, the overall stability of those projects. So, in theory, do you need all that "ceremony and structure"? No, but I can't think of a good reason why you'd go implement all that stuff yourself.
- cheald 14y ago
  Unless I vastly misunderstand your statement, it's nowhere nearly that hairy. https://gist.github.com/3719513 https://gist.github.com/3719513 Did I miss something? Rack is "env variable goes in, array of [code, headers, body] comes out, here are some handy utils for handling grunt work". That's it. That's Rack. You can do whatever you please with it in the middle. That's all that a middleware is, and Rails itself is basically just a collection of Rack middlewares (procs) with some support libraries stapled on. That's a gross simplification, but at the end of the day, that's basically the heart and soul of the framework. My point is that there are multiple levels of abstraction. Of course you don't have to re-write and re-implement boilerplate when you use Sinatra over Rack, just like you don't have to re-write and re-implement when you use Rails over Sinatra. "Rails bad, Sinatra good" is just silly, because it all boils down to what kind of tradeoff you're willing to make between what's done in framework versus what's done in your application.
krichman 14y ago
I get what you are saying, but I feel reducto ad absurdum is unfair here. I understood the parent's point as this; using Sinatra to give yourself the convenience of the {get,post,...} methods for working with HTTP vs. Rails, which forces upon you its more opinionated structure for websites. I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choose as they wish, and Rails might be the more appropriate library is some cases regardless of preference (like in the sibling post about teams). But there's a ton of utility on the spectrum from Rack to Rails and it's perfectly reasonable to choose a midpoint, and perfectly reasonable to choose it because you think Rails is too much but Rack is not enough.
- cheald 14y ago
  I absolutely agree with you. What sticks in my craw is the oft-repeated mantra that "Rails is too heavy" or the perception that Sinatra is doing something that Rails isn't. When you look at Rails as a collection of middlewares (which you can choose!) and support libraries (require 'rails/all' may not be needed!), instead of looking it as a monolithic black box that can't be configured to fit your needs, it's suddenly a lot less "heavy" and a lot more "wow, okay, buffet-style app composition sort of rocks". People seem to have this idea that Rails is on the far end of the "magical and heavy" spectrum, when it can be just about anywhere along the spectrum that you want it to be, based on your selection of middlewares and libraries to use. I have production apps that range from small one-off Rack apps (my dynamic asset server, for example) to Sinatra to full-blown Rails, and they're all very similar beasts. Rails isn't some mystical black box, and Rack isn't just some RFC somewhere, and I think it does a grave disservice to both to marginalize them.
  - krichman 14y ago
    I guess I got the wrong impression from your argument. It all depends on what you are trying to accomplish, as you say.
    - cheald 14y ago
      The reducto ad absurdum was a poor choice, and likely obscured the point, so my fault. :)

by cheald 14y ago

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

You cannot really compare Sinatra with Rails. Rails has scaffolding, DB migrations and all this ultra-highlevel stuff rendering debugging to pure guess-work. Reminds me of doing template-metaprogramming with C++. If it works it's great and the performance rocks, if not you are left alone with cryptic errors and nobody can help you.

jeltz 14y ago
If you want Sinatra with scaffolding there is Padrino which I personally find to have superior scaffolding compared to rails.

ajsharp 14y ago

Whole-heartedly disagree. You can't even parse a json-encoded POST body with plain-vanilla Rack without a middleware from rack-contrib HEAD (the "stable" version is about a year behind the last time I checked). Rack is a standard and abstraction for build ruby app servers and frameworks. To say it's sufficient for building production quality API's is just absurd. One of the main benefits of using frameworks like Sinatra and Rails is that you often don't need to re-write and re-implement all the same boilerplate code (like parsing JSON post bodies) over and over again. And the difference with rails and sinatra vs most other open source projects is the size and activity community, and as a result, the overall stability of those projects. So, in theory, do you need all that "ceremony and structure"? No, but I can't think of a good reason why you'd go implement all that stuff yourself.

cheald 14y ago
Unless I vastly misunderstand your statement, it's nowhere nearly that hairy. https://gist.github.com/3719513 https://gist.github.com/3719513 Did I miss something? Rack is "env variable goes in, array of [code, headers, body] comes out, here are some handy utils for handling grunt work". That's it. That's Rack. You can do whatever you please with it in the middle. That's all that a middleware is, and Rails itself is basically just a collection of Rack middlewares (procs) with some support libraries stapled on. That's a gross simplification, but at the end of the day, that's basically the heart and soul of the framework. My point is that there are multiple levels of abstraction. Of course you don't have to re-write and re-implement boilerplate when you use Sinatra over Rack, just like you don't have to re-write and re-implement when you use Rails over Sinatra. "Rails bad, Sinatra good" is just silly, because it all boils down to what kind of tradeoff you're willing to make between what's done in framework versus what's done in your application.

krichman 14y ago

I get what you are saying, but I feel reducto ad absurdum is unfair here. I understood the parent's point as this; using Sinatra to give yourself the convenience of the {get,post,...} methods for working with HTTP vs. Rails, which forces upon you its more opinionated structure for websites. I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choose as they wish, and Rails might be the more appropriate library is some cases regardless of preference (like in the sibling post about teams). But there's a ton of utility on the spectrum from Rack to Rails and it's perfectly reasonable to choose a midpoint, and perfectly reasonable to choose it because you think Rails is too much but Rack is not enough.

cheald 14y ago
I absolutely agree with you. What sticks in my craw is the oft-repeated mantra that "Rails is too heavy" or the perception that Sinatra is doing something that Rails isn't. When you look at Rails as a collection of middlewares (which you can choose!) and support libraries (require 'rails/all' may not be needed!), instead of looking it as a monolithic black box that can't be configured to fit your needs, it's suddenly a lot less "heavy" and a lot more "wow, okay, buffet-style app composition sort of rocks". People seem to have this idea that Rails is on the far end of the "magical and heavy" spectrum, when it can be just about anywhere along the spectrum that you want it to be, based on your selection of middlewares and libraries to use. I have production apps that range from small one-off Rack apps (my dynamic asset server, for example) to Sinatra to full-blown Rails, and they're all very similar beasts. Rails isn't some mystical black box, and Rack isn't just some RFC somewhere, and I think it does a grave disservice to both to marginalize them.
- krichman 14y ago
  I guess I got the wrong impression from your argument. It all depends on what you are trying to accomplish, as you say.
  - cheald 14y ago
    The reducto ad absurdum was a poor choice, and likely obscured the point, so my fault. :)