Do not use Rails as "Just an API"(web.archive.org)
web.archive.org
Do not use Rails as "Just an API"
https://web.archive.org/web/20130406115821/http://bearsfightingbears.com/do-not-use-rails-as-just-an-api/
6 comments
Url changed from http://bearsfightingbears.com/do-not-use-rails-as-just-an-ap..., which now redirects to a porn site.
You don't pick Rails as the engine for powering your API simply for the asset pipeline, you pick it for all the other stuff @macaw pointed out! If you hook up Sinatra and Sprockets, you are without Rails' ORM, migrations, generators, routing, test infrastructure, plugin ecosystem, and arguably most importantly, the conventions and agility. As you pointed out, the increasingly evident separation between client side JS application and "JSON pump" server side application is useful in that you can swap out the backend far more easily once you have the always increasing performance demands, but until then don't abandon Rails. It's not worth the sacrifice of all the things above simply because it isn't as performant as something else from the get go.
It's pretty trivial to get an ORM standing up in a non-rails environment. Sequel does a great job of this by including bin/sequel so you can run commands like 'sequel migrate' and it just works. There's no reason AR couldn't have it's own bin to manage migrations and model generation so that it not stuck inside of the Rails Rakefile kitchen sink.
All the other stuff you speak of falls in the same category. It's all great code/libs, they just need a CLI so they're not stuck in the monolithic Rails Rakefile.
The good news about Rails 3 is that it fully embraces Rack, so the plugin ecosystem you speak of is much more portable these days if you want to run it in a different framework (I'm thinking of libs like OmniAuth, etc)
Alas, I would never recommend an architecture on the merits alone that you can "swap out the backend". That doesn't really add that much value to end users and never really happens quickly or easily in the real world. The benefit I describe in the blog post to the view layouts and logic being separate is that you get an epic win on the content delivery side of the house. This is a huge deal for mobile web apps.
All the other stuff you speak of falls in the same category. It's all great code/libs, they just need a CLI so they're not stuck in the monolithic Rails Rakefile.
The good news about Rails 3 is that it fully embraces Rack, so the plugin ecosystem you speak of is much more portable these days if you want to run it in a different framework (I'm thinking of libs like OmniAuth, etc)
Alas, I would never recommend an architecture on the merits alone that you can "swap out the backend". That doesn't really add that much value to end users and never really happens quickly or easily in the real world. The benefit I describe in the blog post to the view layouts and logic being separate is that you get an epic win on the content delivery side of the house. This is a huge deal for mobile web apps.
It's not about performance, it's about simplicity. There's just so much to rails that becomes unnecessary if it's just an API.
Sinatra + Sprockets + Sequel seems to be perfectly reasonable.
Sinatra + Sprockets + Sequel seems to be perfectly reasonable.
Let's say I don't want to ship out my whole application package until a user has logged in, so I go to implement a static HTML login page and signup page. Uh oh, I have no template engine! Well just use ERB with Sinatra you say. Fine, cool, I have my form all set up. But wait, how do I tell the user one of their supplied fields is invalid? No build in form validations! Darn. Guess I have to manually code that in. Cool, done. Now lets say I want to let the user know they have signed in successfully. Oh wait, no built in flash mechanism. Cool, I guess I could use Rack::Flash. Or, maybe just the framework that solved this stuff many years ago.
> Uh oh, I have no template engine!
The whole point of this post was using a complete frontend on the client side. Like backbone. You don't render backbone using a server-side template -- it's all done on the client side.
I'm not saying throw out all your old tools. I love using Makefiles. I'm saying use the right tool for the job -- and my opinion is that to have a separate client side app like backbone and a simple server-side API, Rails is way overkill.
The whole point of this post was using a complete frontend on the client side. Like backbone. You don't render backbone using a server-side template -- it's all done on the client side.
I'm not saying throw out all your old tools. I love using Makefiles. I'm saying use the right tool for the job -- and my opinion is that to have a separate client side app like backbone and a simple server-side API, Rails is way overkill.
You're missing the point. The discussion is that some sort of JavaScript stack is handling that stuff and the sever maintains no view state. The benefit is that you can have a more responsive web app that you can easily throw on a CDN and have a snappy end-user experience.
I wholeheartedly agree that for web applications client side applications are the way to go and spend all day every day working on one which we are as you said going to throw on a CDN. I argue however that the experience of sending down the whole asset package (or parts thereof) just to show the login page or other assumedly tertiary screens of the application is worse than rendering that server side and sending it back lickety split. There are other use cases too, you might want to leverage Rails' ability to pump out both XML, and JSON, and maybe capitalize on how easy it is to add new formats like CSV. My point is that you lose _so much_ flexibility to do anything at all server side by ditching Rails that it simply isn't worth the performance increase until you are absolutely sure you should switch and that your requirements are stable. If this is the case it might even be time to ditch Ruby for something more roflscale.
With regards to your other comment, I again disagree. To me it seemed like you were advocating switching off Rails because you were no longer using it's view rendering bits. I say balderdash, as above, I think you will run into weird unforeseen situations which you don't want to implement client side. To your ecosystem point, indeed, decoupling progress has been made and its wonderful to see. It's great for Rails to have stellar competition, but the reason I started using it in the first place is that it took 15 minutes to make a blog. It just works. Smart people have made decisions about what ORM and tempting engine and test framework to use, and how to architect it all in such a way that my teammate and I both know where to find something to change it. I don't want to have to make all those decisions and make all the same mistakes Rails did before arriving at the happy middle ground it has, and I want my teammates to just be able to jump into my project and know how to use the thing.
With regards to your other comment, I again disagree. To me it seemed like you were advocating switching off Rails because you were no longer using it's view rendering bits. I say balderdash, as above, I think you will run into weird unforeseen situations which you don't want to implement client side. To your ecosystem point, indeed, decoupling progress has been made and its wonderful to see. It's great for Rails to have stellar competition, but the reason I started using it in the first place is that it took 15 minutes to make a blog. It just works. Smart people have made decisions about what ORM and tempting engine and test framework to use, and how to architect it all in such a way that my teammate and I both know where to find something to change it. I don't want to have to make all those decisions and make all the same mistakes Rails did before arriving at the happy middle ground it has, and I want my teammates to just be able to jump into my project and know how to use the thing.
I'm doing API first stuff in Sinatra(or grape, or radial-ruby), sequel/mongoid.
Static assets like JS and CSS can live on a CDN. If you need something google friendly on your views render with sinatra and your favorite template language, if not just write straight html/js apps with your favorite js framework.
In a world where you are building API first, what is the point of rails over something lighter and more performant like sinatra?
Static assets like JS and CSS can live on a CDN. If you need something google friendly on your views render with sinatra and your favorite template language, if not just write straight html/js apps with your favorite js framework.
In a world where you are building API first, what is the point of rails over something lighter and more performant like sinatra?
What sucks about Rails is that its a horribly inefficient as a JSON pump in terms of memory consumption; its just not the right tool for the job.
So... a new blog network (domain created last month) finds a hot topic for its authors to argue back and forth in public. It's clever marketing, but I've read enough of TechCrunch.
sick of this bullshit topics. use rails for whatever you fucking need it and if you don't suck you will not have problems. if you suck - that just means YOU suck not rails.