Rails is just an API

http://blog.alexmaccaw.com/rails-is-just-and-api-and-that-s-ok

by maccman • 14 years ago

184 102 14 years ago

blog.alexmaccaw.com

cicloid• 14 years ago

The cherry on top is just coffescript and the new sourcemaps functionality coming from browsers.

Even if you prefer vanilla javascript, still is an awesome combo.

phamilton• 14 years ago

One thing I find interesting is the balance of the Rails model and the Backbone model. On a new project, I generally have fat Rails models and skinny Backbone models. On legacy projects, I put most of the logic into Backbone (since I'd rather not tamper with a legacy backend) making liberal use of parse() and toJSON() in order to get the model the way I want to use it.

Rails/Backbone will work well for the time being but I wonder which way the balance will swing? Will we have fat Rails models or fat Backbone models? If it is a fat Backbone model, then maybe direct database queries is the solution, cutting out Rails entirely. CouchDB and others already support this and could make it even simpler in the future.

MattRogish• 14 years ago

The problem with fat client-side models is that allows malicious users to potentially break your code. Inject bad things. Re-assign users. Etc.

We'll always need some sort of server-side last-mile, tamper-proof validation. So given that, I'm not sure the benefit of duplicating it on the client side.

bdunn3• 14 years ago

This.

You duplicate validation logic on the client side in order to provide rapid feedback to the user. But it's a huge mistake to not let the backend have the final say.

clemesha• 14 years ago

This is how I feel about Flask. I've been using it with Backbone.js and they make a great combo: Flask API serving JSON, and the rest of the logic on the client.

eddie_the_head• 14 years ago

You might find these demoes of Flask with pjax interesting then:

http://flaskpjax.herokuapp.com/automobiles

https://bitbucket.org/a2c/pjax_flask/overview

ch0wn• 14 years ago

If you go down the API route, Flask-Restless[0] and simpleapi[1] are also worth a look.

[0] http://readthedocs.org/docs/flask-restless/en/latest/ [1] https://github.com/flosch/simpleapi

SkyMarshal• 14 years ago

I believe Twitter and Foursquare are doing this too. Their Scala-based appservers are API endpoints, serving JSON to the javascript/Backbone.js frontend.

crusso• 14 years ago

Nice article... very timely and fits in with my perception of where I'm headed with my own Rails development.

I usually just go with wherever the Rails team is taking the framework. For some legacy sites, I may stick with wherever they're headed.

For new projects, I really view Rails as just the web api that feeds my Backbone framework.

lrobb• 14 years ago

The caveats in moving state to the client is that it's a huge perceptual shift for developers, with a steep learning curve.

From my perspective we're coming full circle back to client/server desktop apps... only instead of C++, we're doing it with js inside a browser container... I've done ActiveX controls and Flash components... It's not that much of a stretch.

nirvdrum• 14 years ago

We're also taxing browsers more, while simultaneously trying to run on less-powered devices. It almost defeats the point of a thin client.

emp_• 14 years ago

We have the ways to transfer only data (versus data + markup + DOM triggers) on partial requests with the even less taxing than rendering a full static page.

cs7022• 14 years ago

This is a recurring cycle in application development. We've gone from mainframes and minicomputers serving plain text to dumb terminals, to programs running on personal computers accessing applications and data on servers, to web servers serving structured text to 'dumb' browsers, to powerful in-browser runtime engines accessing applications and data over the web.

There's no magic bullet.

prodigal_erik3• 14 years ago

It is another iteration of that cycle, only this time we have something to lose, namely the web. We are regressing to client/server with a bunch of ever-changing single-site APIs and shoddy client code third parties can't readily fix, and these are destroying the world-wide web of repurposable content in open formats at stable addresses.

discreteevent• 14 years ago

For usability response time is everything. So for the moment if people want to build richer apps then they will have to be asynchronous. But do you think there will ever come a day when you can assume the network is always fast and we will be able to go back around the circle to the mainframe again?

JamesLeonis• 14 years ago

Now that native App-centric ecosystems exist, the client-server model is more pronounced. Supporting these different clients forces this perception shift to a more client agnostic server back end.

__abc2• 14 years ago

I just submitted a talk on this very same notion, "all of this has happened before, and all of this is happening again", in regards to the rebirth of client/server.

It's in both mobile apps, browser based JS app, etc.

My talk was rejected. PUNKS!

hcarvalhoalves2• 14 years ago

Agree, althought I'm not fully convinced the web is fit for "web apps", or that even "web apps" make sense. At least not with current technology.

Developing apps to run on the browser still implies a lot of redundancy: you are forced to work with solutions that weren't created for interactive applications in the first place (HTTP, DOM), limited to one language designed by comitee (Javascript) and code reuse is minimal. Everything just feels hackish (at best) compared to native frameworks (e.g., Apple's Cocoa), and in the end it's hard to achieve good UX and compatibility.

I would rather see more people deploying native aplications with great UX backed by REST APIs than shoe-horning apps into browsers (which break the web).

dantheta• 14 years ago

It's a shame that your post is disappearing into the gray background - I feel something similar every time I have to use Javascript & HTML for a rich interface. Every time that happens, I wish I was using GTK or QT instead.

jiggy20112• 14 years ago

I think there are 4 reasons we are here.

1) Developers are worried that a user won't try their app if they have to install something on their computer.

2) Compatibility , support anything that can render HTML , although this may no longer be the case with the amount of chrome only apps I see.

3) Firewalls, you can get out on port 80 pretty much anywhere, that random port number you decided to use for your app not so much.

4) A few years back web programming was seen as the "easy" way to get into development since writing relatively limited PHP was a lot easier than wrangling C++ and the Windows SDK. Therefor web developers reached critical mass.

Java applets and Flash did a reasonable job with 1 and 2, but they seem to be some of the most hated parts of the web, I think part of this may be because they are see as "too powerful". People want the web to be lightweight.

there• 14 years ago

It took me a bit to realize this wasn't Dustin Curtis' website; is this a theme or what?

Dexec• 14 years ago

http://svbtle.com/

stilldavid• 14 years ago

Maybe check out: http://svbtle.com/

Smudge• 14 years ago

It's a magical theme exclusively available to the few who Dustin Curtis personally invites onto the svbtle.com platform.

endlessvoid94• 14 years ago

Right now 3 of the 5 "members" are arguing on the frontage of HN about rails and APIs.

Now I don't even want an invite.

skeletonjelly• 14 years ago

Elite members of the internet community who may exclusively use this CSS stylesheet. Us internet philistines shouldn't even think about it.

instakill2• 14 years ago

Off-topic but: Anyone know if Alex is hosting the code for that Kudos widget anywhere? Couldn't find it on his Github.

ohgodthecat• 14 years ago

Seems to be a product of the platform http://svbtle.com/

pyrhho• 14 years ago

I didn't notice the 'kudos' button, but went to look at it, and accidentally sent one. Makes me wonder how many of them were accidentally sent by people hovering to see what it was... Aside from the hover-state triggering irreversible action, it's a nice little interaction.

MatthewPhillips• 14 years ago

This feels very conciliatory towards Rails, like that of a boss praising the employee he just demoted.

I'm bearish on Rails because its maintainers don't want it to just be an API. The fight to become the best backend API is much different than the fight to become the best html server. Rails isn't even participating in the fight. Rails has a lot of cruft not needed in an API, Sinatra or Express feel much better for that.

bad_user• 14 years ago

     Rails isn't even participating in the fight

It never did and it shouldn't.

Rails became popular because with it developers had the ability to cut down on soul-sucking activities in their day to day jobs, like building yet another authorization system, or yet another admin. That some people ran with it and scaled it to its limits, that's only because they felt in love with its ease of getting things done.

That's its main advantage. When it comes to getting things done, there's no better alternative.

     The fight to become the best backend API 
     is much different than the fight to become the 
     best html server.

Basically the best backend API is the one that is the fastest / that scales better both horizontally and vertically / that's more malleable to new developments and protocols (e.g. SPDY, Websockets) / that has the least overhead. From that point of view, if you're running on top of a VM that has a GIL, or that doesn't support real thread-based concurrency, then the "battle" is already lost.

So you see, there is no fight. That fight was won long ago by the JVM and the frameworks that run on top of it. Every big website on the web right now (except Microsoft-stuff), runs either on top of the JVM or with custom-baked solutions written in C/C++.

That didn't stop people from building cool stuff on top of PHP, or Rails, or Django, or every other platform that brought instant gratification, but that's another point entirely and we are talking about "battles" here.

jshen3• 14 years ago

"Every big website on the web right now"

Can you define big? I've worked on some big sites that used MRI ruby for APIs and we served a ton of traffic with strict SLAs for a max of 250ms at the 99th percentile and things like that.

lloeki• 14 years ago

> Rails became popular because with it developers had the ability to cut down on soul-sucking activities in their day to day jobs, like building yet another authorization system, or yet another admin.

I beg your pardon, but... what?! Out of the box, Rails has none of this. Rails is almost a meta-framework. Honestly taking your two examples: Devise is horribly complicated and the half-dozen admin frameworks that had a hard time crossing the 3.x line (which is not encouraging for the future) are either generators, downright incomplete enough to be useful outside of a hello world, or frameworks in themselves. I defy anyone beginning with Rails to set up Devise and an admin system in less than half a day, let alone an hour. I'm not trying to pick up a fight, but anecdotally compare this to Django, where setting up both auth and admin is largely under 30min for a newcomer, easy, with ample possibilities left ahead.

So although Rails helps a lot in various areas (like resource routing, respond_to/with), but it still ends up being soul-sucking in numerous others where you have to either delve into needlessly complicated stuff or implement it yourself.

icebraining• 14 years ago

Every big website on the web right now (except Microsoft-stuff), runs either on top of the JVM or with custom-baked solutions written in C/C++.

What does that make Wikipedia (PHP), Craiglist (Perl), Wordpress (PHP) and Youtube (Python[1]) ?

[1] http://www.quora.com/Is-YouTube-still-written-in-Python

instakill2• 14 years ago

So what's the future for Rails? If you talk to the likes of 37Signals and GitHub, it's pjax and server side rendering. This involves fetching a partial of HTML from the server with Ajax, updating the page and changing the URL with HTML5 pushState.

I really hope not. Rails is awesome and I love it to bits, but I will hate to have to use a framework that is massively invested in Ajax/Pjax. The reason for this is simple: UX. Companies don't seem to understand that there's more to the world than just America and America's top-notch Internet [1]. A lot of web traffic comes from places where the connectivity is simply shit and interfaces like Quora, GMail, Twitter et al that have so much functionality with server-side JavaScript as a prerequisite make it seriously difficult to have an enjoyable experience more often than not. If you've ever tried to access Google Analytics on a 1mbps shared connection in a relatively populated office, you'll know what I mean.

Yes of course Ajax and the interactivity and convenience it offers are awesome, but they come at a massive expense, and this is something that will be very saddening if Rails starts considering it as a major part of its core sooner rather than later.

[1] Alright so it's not just America, but my point stands.

untog• 14 years ago

Thing is, AJAX should help with this stuff. No more wasteful page reloads where 90% of the HTML is the same, etc. Granted, we don't see that all the time, but the theory is sound.

stdbrouw• 14 years ago

The point of PJAX, though, is that it's super-easy to have it gracefully degrade, so I wouldn't lump it together with plain AJAX that easily.

virtualeyes6• 14 years ago

quite the contrary, pjax reduces bandwidth and, properly implemented, reduces total # of requests (since once html, css, js, images are downloaded, you just hit the server for the content that varies; usually the page's main content area and title)

can't get much leaner than that. IE 10 supports pushState(), so the future is looking bright.

I's all-in now, give poor ole' JVM beast a break, it might OOME on me if I actually put it to work...

mark_l_watson• 14 years ago

A bit off topic, but: I find that either Rails + pjax or Clojure/Noir + pjax really hits a sweet spot of ease of coding, not too much Javascript, and an AJAXy user experience. Worth spending a little time experimenting with.

bretthopper• 14 years ago

Strange that there's no mention of Rails new/potential "API only" mode: https://github.com/rails/rails/blob/efd557a60cd976ac17be9e23...

This will make it much easier to only use Rails as an API and get rid of a lot of the bloat/complexity people seem to complain about.

This was posted on edgeguides but it's since been removed some reason (http://edgeguides.rubyonrails.org/api_app.html).

jashkenas• 14 years ago

"API only" mode was removed (perhaps temporarily), here: https://github.com/rails/rails/commit/6db930cb5bbff9ad824590...

rbxbx• 14 years ago

https://github.com/lightness/lightrail would seem to be of interest :)

__abc2• 14 years ago

I love how the link to examples for, "the upside of this approach", is his own book.

Now, put that aside, I do agree :)

bdunn3• 14 years ago

Not so fast.

The backend (i.e. Rails) still does almost everything it used to do: validations, access control, session management, data crunching, and everything else that you can't blindly trust a client to do. The real difference with client-side applications is that instead of stitching together view templates and sending back HTML documents, JSON objects are sent back for the client to represent.

More (sometimes duplicate) stuff is added to the client - things like client-side validations, and all the business logic and template code for the purposes of presentation. But no one in their right mind would let their backend blindly consume whatever it gets and persist it without question.

There's still plenty of responsibility for the backend.

orangechicken• 14 years ago

Nowhere was this implied. The article says that Rails makes excellent RESTful APIs. Of course your API should do validations, access control, etc. But, Rails doesn't have to do (much) of the HTML given client-side MVC/MVVM libraries like Backbone and KnockoutJS.

Leave the rendering of the app to the client. Leave the ins and outs of the data to the API (driven by Rails, Node/Express/Railway, Django, what-have-you).

That's definitely applicable to mobile and web apps.

bdunn3• 14 years ago

Right. I guess what I meant is that the backend is still responsible for everything it's always done except for generating HTML views. The rest still applies.

jiggy20112• 14 years ago

So, tell me again why we should be using HyperText Transfer Protocol for doing something that has nothing to do with transferring hypertext?

It would make more sense just to pipe JSON through IRC since it's much less verbose and was designed to be symmetrical (and session based) from the start.

zaius• 14 years ago

The major reason I'm excited about this shift is the potential for higher scalability out of the box. Instead of rendering pages, the server is just for static pages and data. Instead of using a central server to render for each user, it's distributed out to the computing power of all clients.

virtualeyes6• 14 years ago

Yes, agreed, generate static everything on first request; i.e. hit the application server just 1X for live data and generate static file(s) that represent the request on the front end server (httpd, nginx)

That leaves authentication and CRUD operations for the application server to work on; the rest lives in-memory (via google mod_pagespeed, for example) on the front end server.

I'm taking this approach as I like speed, and I don't yet trust the JVM enough to handle tons of live requests and OOME on me while I'm out surfing ;-)

troyk• 14 years ago

Rails is overkill for an api, I think grape https://github.com/intridea/grape has a lot of potential here.

Put node.js in front of something like grape and you have the best of both worlds.

ma2rten• 14 years ago

I tried this approach and it's clearly attractive, but it also has some disadvantages. I decided to switch back to rendering static HTML in Django (not a Rails guy), with just a little JS on top for now. These are my main reasons:

- Debugging on every browser was quite painful. I tried to support IE7+ as well. If a server-side code works, it works for everyone.

- Frameworks on the client-side are not as developed as the server-side ones. Also I am reluctant to introduce more client-side libraries than necessarily, so I will end up coding a lot of stuff, that I can get for free in Django otherwise.

- The user will need to wait for the JS to load and execute until they see something on the first pageload (at least in my implementation).

- If there is a bug in the JS it's harder to get it logged.

mkmcdonald• 14 years ago

Twitter is a perfect example of a "thick client". It's slow, bloated and buggy. When one typo is made in the JavaScript "bundle", the whole site implodes, leaving the user with simply the navigation bar. When JavaScript is turned off, most functionality is lost. I couldn't even log out after disabling JavaScript because "/logout" pointed to a hash.

JavaScript being enabled is not an axiom. The client is a very unstable platform when juxtaposed with the server. A lightweight client facilitates flexibility.

n8agrin7• 14 years ago

Let's say you have a website and let's say that website serves a lot of traffic. Now let's say you relegate Rails to act as just your API because clients are fast now and you want to do some new cool stuff with Javascript also, you're convinced your site is more like an "application". So you build this system and it works really well, except for one thing. The first time you load the page it takes a second or two minimum to get the page loaded. That's ok at first, but really soon it becomes annoying. So you do everything you can with your client, caching whatever possible. You get the load time down to something like 1s. That's better but still not great. Some static sites can spit back pages in like 200ms (across the network!!) and that 800ms difference is crucial to the overall feel and snappiness of your "application". Eventually you give up, you keep the parts of the site that work well as a client-side app, push the rendering back to the server because even though the server is a long ways away from the client and even though clients are fast, you can directly control how quickly the server builds a page and you can optimize that to your heart's content. Now you've gotten your page loads way way down to like 400ms. You're doing great, people love you and you've saved the day. I've fabricated the numbers, but this story is based on truth, because you know who you are? Twitter, Alex's employer.

That's not to say that Rails doesn't make a great API and that Alex doesn't have a point. There certainly is a place for frontend applications out there built on frameworks like Spine, Backbone or Ember (all great projects). Those types of applications have their advantages in some cases. But, it's prudent to be pragmatic and to recognize that the times where you truly need to build a client driven application are few and for the other times Rails is still great at serving up HTML.

virtualeyes6• 14 years ago

Twitter did not think Rails was particularly adequate at serving up anything (for their extreme needs), so they dumped it for the JVM.

Charles Nutter is doing genius work with JRuby, btw, that's where Ruby has a future with the enterprise, on the JVM. Twitter dumping Rails for Scala was a major win for Odersky & friends, and a big hit to Rails (though Ruby/Rails continues to innovate, nothing has changed there)

Not sure why client-side applications take a second or 2 to render a page, but if that is the case, cached html on front end server would be dee way 2 go, just avoid hitting the application server entirely...

n8agrin7• 14 years ago

Twitter didn't dump Rails, or Ruby.

mattmanser2• 14 years ago

Why does a client-side app hand wavingly take a second or two minimum to load compared to the 400ms server-side rendered one?

Exactly the same work is taking place on the server apart from template processing. It makes no sense. If your API is going to be taking 2 secs to build a response, so will your server-side rendered one.

There's no real overhead to DOM insertion and simple template output. If you're doing crazy stuff, it's going to take long wherever you do it.

Admittedly it's still very tricky to get it right at the moment. I also don't really agree with the author's statement about desktop experiences in a browser. I'm beginning to believe it's impossible, especially without the native UX of the OS. I don't think we ever will have that experience as long as there's an address bar, back buttons and all the other cruft at the top of the screen. I think users may always see it as a web page and expect it to behave like a web page. Hopefully I'm wrong.

n8agrin7• 14 years ago

Good question. I should be clear and state that when I say 1-2s page load times I meant the time from when one requests the page to when one can see it. In general API requests are fast, what is slow is having to always deliver a large JS bootstrap across the network (JS files, templates, etc) and then having to make the relevant API requests to produce the UI. Caching is generally touted as a good solution to this problem, but in my experience it tends to be insufficient. Yahoo did an (older now) study showing that 40-60% of visitors arrive at your site having an empty cache (http://www.yuiblog.com/blog/2007/01/04/performance-research-...). Another solution is to pre-fetch data for the UI and deliver that with the bootstrap but it's still difficult to speed up a ~1 or ~2 MB download. This is what really ends up killing the experience.

DrJokepu• 14 years ago

DOM manipulation can be very expensive, especially on IE 6 and 7.

devs1010• 14 years ago

One reason would be if you use a compiled language server side that could be a reason its faster than javascript. another reason would be that rendering pages is usually lighter weight, you already may have a lot of objects in memory on the server, especially if using orm layer caching, etc, as I understand it, a framework like backbone has a slight delay in configuring itself

noelwelsh• 14 years ago

You're assuming your app has to be served as one large chunk of stuff. There are many JS libraries for asynchronously loading additional content, and it is simple enough to use one of these (or implement your own) so that your app is served as one small bootstrap and a bunch of additional content that is loaded as needed.

You say "static sites can spit back pages in like 200ms (across the network!!)". This time is entirely dominated by network latency. There is no way you're getting data to the client in 200ms if they're based in Australia and you're in, say, east coast US. With the client-side model you can push your app's bootstrap to a CDN to get ~200ms latency just about anywhere. You can render the UI and show a "Loading data" spinner to hide the latency of the initial request to your application server. This gives the user the appearance of a snappy site even though network latency might be 1s or more. You can't do this if you go the server-side route.

n8agrin7• 14 years ago

I'm not making any assumptions, I'm telling a story about what I watched happen first hand. As you say, you can split up your assets, that does help significantly. You can also put stuff on CDNs, that helps significantly too. Believe me, Twitter engineers are super smart and they've done all of this. But at the end of the day if your business model depends on people looking and interacting with your content, or if you just want your site to be super fast, having a loading spinner while you wait and download the rest of your application in the background isn't going to cut it.

mattbriggs• 14 years ago

> also, you're convinced your site is more like an "application"

I think thats the big thing. I randomly arrive at tweets all the time, I open gmail once or twice a day and leave it open. Even if you are a heavy twitter user, you are still going to end up loading the page multiple times organically from browsing, even if you leave a main twitter tab open.

The lines are blurring between dynamic content driven websites and web applications, but they are still there. IMO Twitter (and Gawker) got distracted by the new hotness, even if it wasn't appropriate for what they actually are.

prodigal_erik3• 14 years ago

Twitter at least still works. Gawker's server-side rendering is just embarassingly incapable of delivering content at all.

moe4• 14 years ago

because you know who you are? Twitter

No, I'm not twitter. Since when is their incompetence a metric for the capabilities of a technology stack?

You could hand them a top10 supercluster and they'd still failwhale it.

Remember, this is the same company that failwhaled for the better part of 2 years(?) on a pubsub app (one of the most researched and understood areas in computing, cf. telco industry, financial industry).

n8agrin7• 14 years ago

I don't fully understand your point. My quote you're using is meant to be rhetorical. So you're not Twitter... are you implying that you could build an all JS application and avoid all of the problems that Twitter ran into at Twitter's scale? If so, I'd love to see you execute your ideas successfully and explain them so we could all learn from you.

bambax• 14 years ago

> The first time you load the page it takes a second or two minimum to get the page loaded

It doesn't have to. Load the HTML first, which shows something to the user, and load the data asynchronously, and no one will notice.

dblock• 14 years ago

Decent post with the wrong conclusion. Why do I need an MVC to make a RESTful API?

sbecker• 14 years ago

MVC for server-side APIs is still useful because you still need separation of concerns, validations, access control, session management, data crunching, etc on the server.

dhruvasagar• 14 years ago

My only gripe with the shift to client side MVC frameworks and such (which although I like!), is that it often makes handling security (from authorization perspective) a bit difficult, at the end of the day I cannot have my authorization based presentation logic in the front end since it can be easily manipulated.

dkubb• 14 years ago

I don't think anyone is advocating this kind of development. In general you can't trust anything the client tells you, so to release information to a client that has not provided proper authentication credentials to the server is a mistake.

etrain• 14 years ago

Let's talk about context switches here: OMG! it's going to be sooo hard for developers to switch from a model where all the logic happens on the server and where the client is just a dumb display to a model where the all the logic happens on the client and the server just serves as a coordinator.

Oh wait. That already happened, and it was called the switch from mainframes to PCs (or whatever the fuck you want to call it). The point is: developers adapted, and got over it, and you will too.

The question I (and everyone in this community) have (or should have) is - are there strong technical foundations for this switch? Is Javascript the right client-side interpreted language to support every conceivable application over the next 10 years? Is HTML the right display/templating language?

My answer: no, not at all. But it's hard as hell to fight the momentum of an unstoppable force. Even with an immovable object.

akurilin• 14 years ago

I'd love to know what people think the current "state of the art" stack is for rich and highly scalable web applications, something that has been proven to work great in production by big projects. Is it nginx + Rails + Backbone? When I think of fast rich web apps, Facebook and StackOverflow come to mind, and as far as I remember, neither use the above-mentioned tools (not that it means they're bad in any way).

Just a couple of years ago Rails-generated HTML pages were super hot, and now people are almost insulted if you don't have a fairly complex Javascript framework running the show.

regularjack2• 14 years ago

What about graceful degradation? Making JavaScript a requirement instead of an addition is plain wrong and goes against the essence of the Web.

rimantas• 14 years ago

Only if "Web" for you consist of mostly static content. For others there is an interesting thing called Web Applications. How do you gracefully degrade a game done with all cool stuff HTML5 and friends offer?

regularjack2• 14 years ago

No, I'm not talking about static content, I am talking about dynamic content, which is exactly what Rails is there for. If you only have static content you don't even need Rails, just have the web server deliver it.

I was not talking about "Web Applications" either, which, FYI, are not the same thing as dynamic content. I realize that he mentions in the post that he's mostly talking about Web Applications, but then he's just stating the obvious and the post title should be "For Web Applications, Rails is just an API".

Rails is just an API

Related Stories