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

61–70 of 114 posts

Re: Rails is just an API

#61

Post by jshen »

virtualeyes wrote: post #53
jshen wrote: post #43

Earlier quoted context omitted.

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

oh, Twitter (Scala/Java), American Airlines (Java), Facebook (on HipHop in C++), Stackoverflow (C#), ESPN (Java) I think by big that's a code word for enterprise. The big sites you have worked on are comparatively small if Ruby is backing the show. That's not to take away from the ton of traffic that you guys were able to serve; it's just that there are few enterprise level Ruby backed sites running these days. Githu…

That's not a clear definition. If I guess what you are implying is that "big" means a top 100 site. Enterprise is not the same thing as big, at all. They may co-occur often, but they are orthogonal.

"The big sites you have worked on are comparatively small if Ruby is backing the show."

That's a big assumption. You have no idea who I am or what I've worked on. One of the sites I worked on was yellowpages.com. That's a top 1000 site, but even that doesn't tell the full story. When I was there we were serving ads for most requests to bing maps. Do you consider bing maps comparatively small?

I currently work for disney who runs espn.go.com. The person sitting next to me right now worked on espn.go.com before she transferred to my group. I can assure you that espn.go.com could easily be served with ruby instead of java.

I'm questioning a couple of specific claims made by bad_user. That all big sites use the JVM or c/c++ or .net. I think that is false, or the definition of "big" is so narrow as to be meaningless for 99.9% of programmers. I'm also questioning the claim that the best backend is the one that is the fastest. I'd argue that the best backend is the one that is fast enough and the cheapest, wouldn't you agree? As I mentioned before, I was working on an api that served requests for bing maps with a very tight SLA. We ran it on MRI ruby, and we met the SLA.

Here's something that people often forget, you can put things like varnish in front of your API. This doesn't work for everyone, but if you're API is easily cached, then you shouldn't have any problems scaling it even if you're using a language like MRI ruby which has a GIL.

Re: Rails is just an API

#62

Post by [deleted] »

virtualeyes wrote: post #54
n8agrin wrote: post #52

Earlier quoted context omitted.

Twitter didn't dump Rails, or Ruby.

Yes, you're correct, it was not an either-or proposition, I'm sorry, they dropped them both. Seriously, I'm curious, what public facing, or any facing, components does Twitter use that is written in Ruby and/or Rails? A Google search for "twitter rails" brings up the usual got dumped threads. A similar search, but this time, "twitter scala" brings up, as a first result "Scala School" for Twitter engineers, followed b…

[deleted]

Re: Rails is just an API

#63

Post by [deleted] »

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…

[deleted]

Re: Rails is just an API

#65

Post by mattmanser »

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…

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.

Re: Rails is just an API

#66

Post by rbxbx »

jashkenas wrote: post #23
bretthopper wrote: post #21

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

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

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

Re: Rails is just an API

#67

Post by jiggy2011 »

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…

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.

Re: Rails is just an API

#68

Post by getsat »

virtualeyes wrote: post #54
n8agrin wrote: post #52

Earlier quoted context omitted.

Twitter didn't dump Rails, or Ruby.

Yes, you're correct, it was not an either-or proposition, I'm sorry, they dropped them both. Seriously, I'm curious, what public facing, or any facing, components does Twitter use that is written in Ruby and/or Rails? A Google search for "twitter rails" brings up the usual got dumped threads. A similar search, but this time, "twitter scala" brings up, as a first result "Scala School" for Twitter engineers, followed b…

I have multiple friends working at Twitter. The frontend is still all Rails.

Re: Rails is just an API

#69

Post by n8agrin »

mattmanser wrote: post #65
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…

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

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.
Post reply on HN