Modern Web Application Architecture

I am guessing there are some access right restrictions to the API and they haven't added anything like OAuth yet. That's why they need to proxy for it (hunch based on the use of word api-internal in the post).

Another reason might simply be they just don't have the right people to develop the JS front-end.

While I agree on the 100% js. To optimize the experience and app load time its best to provide the data on load inside the document. reducing http calls. backbone supports the idea here:

http://documentcloud.github.com/backbone/#Collection-reset

Aside from the API having no access restrictions (and therefore has to be internal), it's providing pure data, no html.

The template rendering would have to be done in JS, which means that the templates have to be delivered to the browser. Either you load every template when you need it or you have to transfer all templates on page load. The first case has no advantage over a simple application layer on the server and the second increases page load time.

Thought further, some older mobile phones might have a hard time rendering complex templates in JS, so that might be another factor.

He should just do what best fits his requirements, and that might require a simple application layer in front of the api.

Exactly my thought: why have one server proxy request to another Web server instead of having the client use the API directly?

Your main Web server could just serve the initial page / application / whatever, and then the application lives on the client, fetching data from the API and formatting it as needed. You end up with proper MVC in the browser.

That's what I did for a small side-project of mine last week and it worked very well. I detailed how I built it here: https://plus.google.com/118077068834135870002/posts/62agb7qp...

This pattern is very interesting, although I'm finding I develop a quite a bit faster on server side frameworks like Flask/Django... One thing I don't like about the pattern is that you have to send the templates to all the users (static), even users that don't have access to the those pages (for example, an admin page). Have you run into this? Of course you could also send the templates via JSON...

Or a hybrid: serve templates/views/html/etc as usual but Ajax straight to the API/db.

maybe this: http://news.ycombinator.com/item?id=3200709

He talks about wanting to charge for the API. If the javascript on your public website directly calls your (otherwise paid) API, how can you avoid exposing the credentials it uses which are unmetered?

aeden, I agree with you that the disadvantage of this approach is that you can't just repackage the client as a mobile app.

However, there are two reasons why you would access the API with server side code in a web client (as opposed to a mobile one).

[1] You can provide a Google friendly, static (no javascript) version of the site and all content - as opposed to a completely invisible site from an SEO perspective.

[2] You can store local versions of all data that's returned from API calls.

This is useful in a couple of ways.

[a] It means that you need only check the API for a 'last modified' date and, if it's older than the current date, use the locally cached API call results first (if they exist). This makes the client extremely fast, since you're reading flat files locally.

[b] If the API is inaccessible for some reason, the client can default to using the locally cached copies of previous API call results

I built this site (backend, not the HTML/CSS/JS) the same way a while back and have been pleasantly surprised with the results - http://jacksonteece.com/

My understanding of Amazon's internal SOA usage is that it is geared toward timeout-enforced service response guarantees to mitigate concerns about performance penalty. Specifically, a page render event triggers initiation of asynchronous calls to N service endpoints( I have read as many as 300 per page render event ). The page renderer will wait for a specified time to receive responses from each service, but timeout on those services that do not meet their latency SLA. Page components with dependencies on either error result or timed-out service responses will simply be not rendered or replaced with dummy content.

Employees of Amazon, feel free to correct any holes or errors in my understanding of the web application architecture there.

Harel, I'd be very interested in seeing some of the projects you've done using this technique. Are there any that are publicly accessible?

Yep, thats a big reason. Always load the possible next actions upfront, and when the user clicks, its immediate.

I posted a question on stackoverflow trying to gather pros and cons of the methods outlined in this HN post.

http://stackoverflow.com/questions/8022715/standalone-rails-...

Use HTTPS? Or do you mean security against other kinds of attacks besides sniffing and MITMing?

A resource is not a record.

I can imagine performance being an issue (as mentioned in the article, but without any numbers) - anyone know of any benchmark results?

I have a similar architecture for http://www.mockuptiger.com

It is php+jquery+mysql

I use adodb library but I think PDO is now quite mature so will consider that for other enhancements

We can't tell you if this is a good idea without knowing what your project is.

In the absence of that, here's some "possible" criticisms, some of which come directly from the blog post itself:

You're incurring extra latency by doing two HTTP connections where one might do.

If you choose to serve your REST API from a different layer of servers than your front end, that's a whole new layer of servers that can go down. So you have a whole new layer of redundancy and failover to engineer.

Your back end is issuing SQL queries, encoding the results as JSON or (god help us) XML, passing it to your front end which is very likely parsing it, filling out templates with the resulting data structure, and emitting HTML. That extra encode-and-parse step costs time and resources. (Of course, if your front end is generally Javascript running on the customer's machine, this isn't a big problem.)

Finding bugs can be a pain. You now need multiple layers of logging, and tracing a buggy request through the system requires you to piece together a chain of internal requests.

You've designed twice the surface area of API. You must now document and test an internal API as well as your front end, and the two may have significantly different semantics. Now, it's true: Just because you don't formally define your internal API doesn't mean it isn't there, because every app has some sort of internal API (often built around an ORM, these days). But once you decide to formalize it that API is harder to tinker with.

The overarching criticism, as always, is: YAGNI. You are almost certainly not building Facebook. For a very large percentage of the sites on the web, this design is total overkill. If you're delivering text embedded in HTML, like most blogs or magazines or brochureware sites, you should spend your energy figuring out the Varnish and CDN layers instead of fiddling around with a custom REST API that nobody is ever going to use. Just install an off-the-shelf RSS module and call it a day.

Even if your site might potentially benefit from an internal API, should it really be part of your initial deliverables? Does the customer want to pay for it? Does the minimum viable product require it? If there is anything more painful than designing one interface for the wrong product, it's designing two interfaces for the wrong product.

Having said all of that: This architecture is indeed really useful when you have the right problem, we use something like it at my own company, and (as many other commenters have pointed out) in the world of rich Javascript clients and native mobile apps this strategy is gaining in popularity for good reason.