Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails is just an API

blog.alexmaccaw.com

Post reply on HN
Print view View original

41–50 of 114 posts

Re: Rails is just an API

#41

Post by hcarvalhoalves »

lrobb wrote: post #6

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.

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

Re: Rails is just an API

#42

Post by bdunn »

orangechicken wrote: post #38
bdunn wrote: post #27

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…

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). T…

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.

Re: Rails is just an API

#43

Post by jshen »

bad_user wrote: post #37
MatthewPhillips wrote: post #12

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…

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 m…

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

Re: Rails is just an API

#44

Post by cs702 »

prodigal_erik wrote: post #34
cs702 wrote: post #20

Earlier quoted context omitted.

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.

It's the prisoner's dilemma: yeah, everyone on the web would be better off if businesses weren't doing this, but individual businesses will continue to do it as long as it's in their best interest to retain very tight control of and limit third-party access to the data and meta-data they capture from users.

I'm not sure how or even if the infrastructure of a distributed system like the web could be engineered so as to prevent this kind of situation. Perhaps the solution is to build in a system of financial incentives -- not unlike what the Bitcoin folks have done to solve the Byzantine Generals problem. It's an interesting problem.

Re: Rails is just an API

#45

Post by ma2rten »

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.

Re: Rails is just an API

#46

Post by n8agrin »

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.

Re: Rails is just an API

#47

Post by jhickner »

prodigal_erik wrote: post #34
cs702 wrote: post #20

Earlier quoted context omitted.

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.

Aren't we just embracing the difference between a site and an API? It's hard to do both well at the same URL. The API provides the repurposable content in an open format, and the site itself is free to experiment with different presentations. Is that so bad?

Re: Rails is just an API

#48

Post by virtualeyes »

n8agrin wrote: post #46

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 min…

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

Re: Rails is just an API

#49

Post by lloeki »

bad_user wrote: post #37
MatthewPhillips wrote: post #12

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…

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 m…

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

Post reply on HN