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.
Rails is just an API
31–40 of 114 posts
Re: Rails is just an API
#32Earlier quoted context omitted.
We're also taxing browsers more, while simultaneously trying to run on less-powered devices. It almost defeats the point of a thin client.
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.
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.
Re: Rails is just an API
#33Off-topic but: Anyone know if Alex is hosting the code for that Kudos widget anywhere? Couldn't find it on his Github.
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.
Re: Rails is just an API
#34The 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.
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.
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.
Re: Rails is just an API
#35Rails 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.
Re: Rails is just an API
#36The 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.
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 ;-)
Re: Rails is just an API
#37This 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…
Rails isn't even participating in the fight
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.
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.
Re: Rails is just an API
#38Not 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…
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.
Re: Rails is just an API
#39So 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…
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...
Re: Rails is just an API
#40This 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.
I believe Twitter and Foursquare are doing this too. Their Scala-based appservers are API endpoints, serving JSON to the javascript/Backbone.js frontend.