15 ms·

Rails is just an API

184 points by maccman 15y ago

cicloid 15y 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 15y 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 15y 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.
  - bdunn 15y 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.
    - krsunny 15y ago
      Are you saying duplicating code is ok if only to make the app appear faster? I've often wondered that myself.
clemesha 15y 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 15y ago
  You might find these demoes of Flask with pjax interesting then: http://flaskpjax.herokuapp.com/automobiles http://flaskpjax.herokuapp.com/automobiles https://bitbucket.org/a2c/pjax_flask/overview https://bitbucket.org/a2c/pjax_flask/overview
  - ch0wn 15y 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/ http://readthedocs.org/docs/flask-restless/en/latest/ [1] https://github.com/flosch/simpleapi https://github.com/flosch/simpleapi
    - Ecio78 15y ago
      Is there any of this solution that bundles with an easy mobile library/sdk? I was asking for something like a semicomplete backend opensource solution here http://news.ycombinator.com/item?id=3735387 http://news.ycombinator.com/item?id=3735387 but unfortunately I got no responses
- SkyMarshal 15y 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 15y 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 15y 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 15y 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_ 15y 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.
    - mgkimsal 15y ago
      is it really "less taxing"? An app page that polls every few seconds to get back an empty JSON block is going to be eating up the network radio on a smartphone constantly, vs just getting back 120k HTML page, and a few CSS/image requests one time over, that may then sit there and be read (or a form filled out) for the next few minutes.
- cs702 15y 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_erik 15y ago
thetroll 15y ago
we've adapted this kind of style 3 years ago on one project and have worked quite well for us. and i think now it's going to be better with the likes of https://github.com/nesquena/rabl https://github.com/nesquena/rabl and https://github.com/rails/jbuilder https://github.com/rails/jbuilder on the view layer
there 15y ago
It took me a bit to realize this wasn't Dustin Curtis' website; is this a theme or what?
- Dexec 15y ago
  http://svbtle.com/ http://svbtle.com/
- stilldavid 15y ago
  Maybe check out: http://svbtle.com/ http://svbtle.com/
- Smudge 15y ago
  It's a magical theme exclusively available to the few who Dustin Curtis personally invites onto the svbtle.com platform.
- endlessvoid94 15y 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 15y ago
  Elite members of the internet community who may exclusively use this CSS stylesheet. Us internet philistines shouldn't even think about it.
instakill 15y 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 15y ago
  Seems to be a product of the platform http://svbtle.com/ http://svbtle.com/
- pyrhho 15y 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 15y 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 15y 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.
  - jshen 15y 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.
deleted 15y ago
[deleted]
instakill 15y 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 15y 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 15y 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.
- virtualeyes 15y 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...
bretthopper 15y ago
Strange that there's no mention of Rails new/potential "API only" mode: https://github.com/rails/rails/blob/efd557a60cd976ac17be9e238111a551599caeb5/railties/guides/source/api_app.textile 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 http://edgeguides.rubyonrails.org/api_app.html).
- jashkenas 15y ago
  "API only" mode was removed (perhaps temporarily), here: https://github.com/rails/rails/commit/6db930cb5bbff9ad824590b5844e04768de240b1 https://github.com/rails/rails/commit/6db930cb5bbff9ad824590...
  - rbxbx 15y ago
    https://github.com/lightness/lightrail https://github.com/lightness/lightrail would seem to be of interest :)
__abc 15y 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 :)
bdunn 15y 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 15y 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.
  - bdunn 15y 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.
  - jiggy2011 15y 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.
    - mbell 15y ago
      >So, tell me again why we should be using HyperText Transfer Protocol for doing something that has nothing to do with transferring hypertext? Because its the best option. When WebSockets what whatever socket protocol becomes ubiquitous you'll probably see less HTTP use.
zaius 15y 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.
- virtualeyes 15y 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 15y ago
Rails is overkill for an api, I think grape https://github.com/intridea/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 15y 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 15y 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.
n8agrin 15y 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.
- virtualeyes 15y 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...
dblock 15y ago
Decent post with the wrong conclusion. Why do I need an MVC to make a RESTful API?
- sbecker 15y 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.
a15i 15y ago
typical use of '<something well known> is crap' to attract some attention, bringing some traffic. no real value in the content.
dhruvasagar 15y 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 15y 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 15y 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 15y 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.
- virtualeyes 15y ago
  Facebook is PHP (with C++ pre-processor called HipHop). StackOverflow is, ta da, M$ stack (C#, SQL Server, etc.) State of the art in highly scalable web apps? Try this: 1) Apache 2.4 proxy/load balancer + mod_pagespeed 2) Scala microframework (Scalatra, Spray, or Unfiltered) 3) ScalaQuery functional JDBC wrapper (A-R-ish analogue) 4) Scalate pre-compiled templatye engine 5) pjax pushState + dataTables + FancyBox (modals) 6) Jedis in-memory cache for the content that varies 7) static html templates served off of CDN Of course, the app server can be anything (Rails, Django, heck, even PHP) with sufficient caching. I really like Scala right now, it's the new hotness: terse syntax, functional, compile-time checked, and ba-blazin' fast, wahoooooo ;-)
justinbaker 15y ago
Too much talking about apps. Not enough writing apps...
regularjack 15y 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 15y 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?
  - regularjack 15y 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".
    - virtualeyes 15y ago
      Rails is there to generate static content as the alternative, hitting the Rails stack for live data, is asking for trouble -- just ask Twitter ;-) Of course by saying such a thing on a Rails thread, I am clearly asking to accrue yet more karma. I can take it, the truth hurts, I'm a compile time Boddhisatva brought here to enlighten the heathens, willing to descend into runtime hell to save all beings and bring them to the other shore of static compilation. May all beings be snappy (and never sluggish)

184 points by maccman 15y 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 15y 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 15y 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.
- bdunn 15y 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.
  - krsunny 15y ago
    Are you saying duplicating code is ok if only to make the app appear faster? I've often wondered that myself.

clemesha 15y 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 15y ago
You might find these demoes of Flask with pjax interesting then: http://flaskpjax.herokuapp.com/automobiles http://flaskpjax.herokuapp.com/automobiles https://bitbucket.org/a2c/pjax_flask/overview https://bitbucket.org/a2c/pjax_flask/overview
- ch0wn 15y 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/ http://readthedocs.org/docs/flask-restless/en/latest/ [1] https://github.com/flosch/simpleapi https://github.com/flosch/simpleapi
  - Ecio78 15y ago
    Is there any of this solution that bundles with an easy mobile library/sdk? I was asking for something like a semicomplete backend opensource solution here http://news.ycombinator.com/item?id=3735387 http://news.ycombinator.com/item?id=3735387 but unfortunately I got no responses
SkyMarshal 15y 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 15y 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 15y 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 15y 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_ 15y 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.
  - mgkimsal 15y ago
    is it really "less taxing"? An app page that polls every few seconds to get back an empty JSON block is going to be eating up the network radio on a smartphone constantly, vs just getting back 120k HTML page, and a few CSS/image requests one time over, that may then sit there and be read (or a form filled out) for the next few minutes.
cs702 15y 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_erik 15y ago

thetroll 15y ago

we've adapted this kind of style 3 years ago on one project and have worked quite well for us. and i think now it's going to be better with the likes of https://github.com/nesquena/rabl https://github.com/nesquena/rabl and https://github.com/rails/jbuilder https://github.com/rails/jbuilder on the view layer

there 15y ago

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

Dexec 15y ago
http://svbtle.com/ http://svbtle.com/
stilldavid 15y ago
Maybe check out: http://svbtle.com/ http://svbtle.com/
Smudge 15y ago
It's a magical theme exclusively available to the few who Dustin Curtis personally invites onto the svbtle.com platform.
endlessvoid94 15y 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 15y ago
Elite members of the internet community who may exclusively use this CSS stylesheet. Us internet philistines shouldn't even think about it.

instakill 15y 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 15y ago
Seems to be a product of the platform http://svbtle.com/ http://svbtle.com/
pyrhho 15y 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 15y 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 15y 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.
- jshen 15y 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.

deleted 15y ago

[deleted]

instakill 15y 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 15y 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 15y 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.
virtualeyes 15y 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...

bretthopper 15y ago

Strange that there's no mention of Rails new/potential "API only" mode: https://github.com/rails/rails/blob/efd557a60cd976ac17be9e238111a551599caeb5/railties/guides/source/api_app.textile 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 http://edgeguides.rubyonrails.org/api_app.html).

jashkenas 15y ago
"API only" mode was removed (perhaps temporarily), here: https://github.com/rails/rails/commit/6db930cb5bbff9ad824590b5844e04768de240b1 https://github.com/rails/rails/commit/6db930cb5bbff9ad824590...
- rbxbx 15y ago
  https://github.com/lightness/lightrail https://github.com/lightness/lightrail would seem to be of interest :)

__abc 15y 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 :)

bdunn 15y 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 15y 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.
- bdunn 15y 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.
- jiggy2011 15y 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.
  - mbell 15y ago
    >So, tell me again why we should be using HyperText Transfer Protocol for doing something that has nothing to do with transferring hypertext? Because its the best option. When WebSockets what whatever socket protocol becomes ubiquitous you'll probably see less HTTP use.

zaius 15y 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.

virtualeyes 15y 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 15y ago

Rails is overkill for an api, I think grape https://github.com/intridea/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 15y 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 15y 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.

n8agrin 15y 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.

virtualeyes 15y 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...

dblock 15y ago

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

sbecker 15y 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.

a15i 15y ago

typical use of '<something well known> is crap' to attract some attention, bringing some traffic. no real value in the content.

dhruvasagar 15y 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 15y 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 15y 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 15y 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.

virtualeyes 15y ago
Facebook is PHP (with C++ pre-processor called HipHop). StackOverflow is, ta da, M$ stack (C#, SQL Server, etc.) State of the art in highly scalable web apps? Try this: 1) Apache 2.4 proxy/load balancer + mod_pagespeed 2) Scala microframework (Scalatra, Spray, or Unfiltered) 3) ScalaQuery functional JDBC wrapper (A-R-ish analogue) 4) Scalate pre-compiled templatye engine 5) pjax pushState + dataTables + FancyBox (modals) 6) Jedis in-memory cache for the content that varies 7) static html templates served off of CDN Of course, the app server can be anything (Rails, Django, heck, even PHP) with sufficient caching. I really like Scala right now, it's the new hotness: terse syntax, functional, compile-time checked, and ba-blazin' fast, wahoooooo ;-)

justinbaker 15y ago

Too much talking about apps. Not enough writing apps...

regularjack 15y 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 15y 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?
- regularjack 15y 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".
  - virtualeyes 15y ago
    Rails is there to generate static content as the alternative, hitting the Rails stack for live data, is asking for trouble -- just ask Twitter ;-) Of course by saying such a thing on a Rails thread, I am clearly asking to accrue yet more karma. I can take it, the truth hurts, I'm a compile time Boddhisatva brought here to enlighten the heathens, willing to descend into runtime hell to save all beings and bring them to the other shore of static compilation. May all beings be snappy (and never sluggish)