Hacker News Reader

Comment by aeden | Hacker News Reader

I think you should take the frontend one step further and have it live completely on the client side. It is fully within the realm of possibility to build a JavaScript/HTML application for the front end that only interacts with your API.

Is there a reason you didn't do this?

View on HN

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

Thanks for the link, I'll check it out.

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?

You could make sure that the requesting page is on your domain.

It's trivial to use a proxy to modify the referral headers.

I recall some functionality in a PHP framework I was using that allowed you to make API calls on the server side through use of a class or function. It was something like

    $user = $api->GET('/accounts/the_user');

which would process the API call without actually making a separate HTTP request. Would this accomplish it?

Make the calls to the API over HTTPS.

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/

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

Well in my case I wrote a little packer / minifier for compiled Jade (http://jade-lang.com/) templates and serve them as a single JavaScript file.

When you have different templates based on user rights, you should probably make different packed template files and serve them only to users with the proper cookie / session rights.

I'd serve an admin page / app at a specific URL and then it would reference the proper template JS file (or whatever you're using).

Either way I wouldn't worry about the extra few bytes served for rarely used templates, just make sure the template file is properly cached. Or serve it as a different file and load it asynchronously when needed.

Oh yes, its not the page size I worry about, but whether the template already has some info that you don't want to share (OK, probably most interesting info is dynamic, but anyway)

If anyone's interested, I put up the code I wrote for packing Jade templates into a single file and serving them to the client with Express: http://pastebin.com/kRtCJHYH (feel free to do whatever you want with it)

I found there were very few good alternatives for using Jade template client-side. The only one that seems promising is JadeVu (https://github.com/LearnBoost/jadevu/) but the approach is very different.

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

Reply on news.ycombinator.com