
Do not use Rails as "Just an API" - bradgessler
https://web.archive.org/web/20130406115821/http://bearsfightingbears.com/do-not-use-rails-as-just-an-api/
======
dang
Url changed from [http://bearsfightingbears.com/do-not-use-rails-as-just-an-
ap...](http://bearsfightingbears.com/do-not-use-rails-as-just-an-api/), which
now redirects to a porn site.

------
hbrundage
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.

~~~
endlessvoid94
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.

~~~
hbrundage
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.

~~~
bradgessler
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.

~~~
hbrundage
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.

------
programminggeek
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?

------
cagenut

      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.
    

This really only matters on tiny vps servers for low/no-revenue companies. RAM
is sooo cheap that if even _one_ little feature of rails saved a dev-week then
it will have paid for itself.

------
Harkins
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.

------
keymone
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.

