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

91–100 of 114 posts

Re: Rails is just an API

#91

Post by bambax »

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…

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

Re: Rails is just an API

#92

Post by prodigal_erik »

jhickner wrote: post #47
prodigal_erik wrote: post #34

Earlier quoted context omitted.

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?

Before devs started experimenting with client-side rendering, all sites' content was amenable to the same set of tools. Now there are more and more services with broken frontends and unique APIs which are incompatible with everything else and aren't even stable—when you can rev your own client js instantly, you don't know or care whether any other clients broke. I'm stuck using only one client (your js) that works at all and I can't fix it, which is almost everything that client/server got wrong the first time around. It's not impossible to carefully implement a stable form-compatible API in common with a bunch of similar sites, but I don't see it happening.

Re: Rails is just an API

#93

Post by prodigal_erik »

mattbriggs wrote: post #74
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…

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

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

Re: Rails is just an API

#94

Post by virtualeyes »

jshen wrote: post #61
virtualeyes wrote: post #53

Earlier quoted context omitted.

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…

Exactly, with caching the application server becomes far less of an issue. There's a catch, though.

Twitter, is a live service, content is constantly changing, which means round-trip to app server required, and that is where dynamic languages suffer, under load.

re: "I can assure you that espn.go.com could easily be served with ruby instead of java.", perhaps, but like Twitter, they chose the JVM and not the Ruby runtime. That's the "big site" de facto choice, compilation over runtime, whether it be .NET, JVM, or, perhaps in future for the enterprise, functional a la Haskell, Erlang, etc.

re: the best backend being the cheapest, depends on what you mean, hardware is not everything, the application has to be developed and maintained, bandwidth accounted for, etc. But yes, I can roll with that, minimal hardware expense to get the job done. Now, if you're implying that compiled languages are more expensive than their dynamic language counterparts, not sure if that is necessarily the case.

I run a couple of Dell R610 ESXi servers in colo, small setup, but complete overkill for actual load we're handling. At any rate, Scalatra (Scala Sinatra clone) running on Jetty "costs" 38MB of RAM per instance, not exactly expensive.

Re: Rails is just an API

#95

Post by eyko »

DrJokepu wrote: post #82
mattmanser wrote: post #65

Earlier quoted context omitted.

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…

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

And even in Firefox and Chrome. In fact, I'd ask most of these web application developers to try browsing the modern web on a relatively modern computer: my 1ghz athlon with 1GB RAM… Even twitter is dead slow. DOM manipulation is slow, CSS transitions are slow, infinite scrolling is a memory hog, fake smooth scrolling (disregarding the browser's native scrolling) is slow… everything is just a pain.

Re: Rails is just an API

#96

Post by virtualeyes »

akurilin wrote: post #87

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…

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

Re: Rails is just an API

#98

Post by rimantas »

regularjack wrote: post #97

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

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?

Re: Rails is just an API

#99

Post by mattmanser »

n8agrin wrote: post #79
mbell wrote: post #75

Earlier quoted context omitted.

Bad design. Only pull the bare minimum to render the initial page on the first request, load everything else you need, when you need it, asynchronously in the background. There is no way the 'bootstrap' is 1-2MB. There is absolutely no reason to load every single bit of javascript you could ever need on the first page load just like you don't load every image on your site on the first request.

It's really easy to armchair-engineer and just declare bad design. What's harder is to actually build a system that scales well in the very unusual circumstance that sites like Twitter, Google and Facebook find themselves in. Let's take your solution: it's really difficult to build a development environment that allows a large team to work efficiently which is not based on having essentially a single bootstrap file w…

I do agree it's very hard still and that many of the 'it's just an API' posts are wishful thinking for the next year or two.

However twitter is a perfect example of how not to do it, they inadvertently shot themselves in the foot with the hashbangs so they never know in the first request what's being asked for. That's kind of a mix between HTML5 history being so slow to come out and Google encouraging the # stuff in the first place. But everyone's still learning. Full page postback-less js applications are still a pretty new field.

Twitter were a very early trail blazer. As much as people hate it, kudos to them for having the balls to try it and let us all learn from their mistakes. I've got a project that's a horrible mix between postback and postbackless stuff. It's almost dailyWTF worthy, but I don't regret doing it as it's getting closer to getting it done right. And there are people using it right now and it works as much as I cringe about it.

For example if you look at the 1.5Mb js file they send when I do an anonymous request, it's got every possible action I could ever do regardless of whether you're on a tweet page, the main page, a profile page, etc. It doesn't matter if I'm signed in or not. They're all in there as templates. And then for some reason they wack in a load of compressed jQuery stuff, etc. It has how to sign up, how to add people to follow, congratulation screen for when your first few follows, etc.

That, to me, is just nuts. Why is there no split in the js dependant on the kind of user they're going to be? On reflection they probably think that too.

With regards to development environments, I do think you should force your programmers to understand your infrastructure. Give new programmers a couple of simple examples to play with on how to manage dependencies and loading files and that's that. In my view it's no different to saying 'we use these parts of C++, not these' or 'this is our coding style, you must follow it or your checkins will be rejected'. Or 'this is how the industry this app is for works, these are the general business rules most of them have, this is the general workflow'.

New programmers to your organisation always have to pick up some contextual information over time. It's your job to train them in the most relevant key information asap. I think far too often it's just a case of 'you're a programmer you're smart, let's just throw you in at the deep end and see if you can swim. Oh, why did you swim into the shark pen? Silly n00b.'. Very relevant: http://news.ycombinator.com/item?id=3736800

Re: Rails is just an API

#100

Post by moe »

n8agrin wrote: post #81
moe wrote: post #80

Earlier quoted context omitted.

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

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.

Yes, I'm implying that. I have personally done it for smaller apps. Google and others are demonstrating it with gmail et al, at a significantly higher complexity than twitter.

It's nonsensical to conclude "Twitter can't do it so it isn't possible".

I maintain twitter.com is slow because twitter is incompetent or doesn't care about their product.

When you look at what the page actually does then there's no reason why it has to be a 2MB download. There's also no reason why any javascript (other than a couple hundred bytes) needs to be loaded synchronously. There's no reason they can't serve direct tweet links as static HTML and upgrade the page post-load or when the user starts interacting with it. There's no reason the page needs to flicker for 2-3 seconds post-load before becoming usable.

These are all symptoms of sloppy engineering.

Post reply on HN