5 ms·

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 Jav

by aeden 15y ago

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?

elisee 15y ago
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/62agb7qpUNU https://plus.google.com/118077068834135870002/posts/62agb7qp...
- leftnode 15y ago
  Thanks for the link, I'll check it out.
swah 15y ago
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...
- elisee 15y ago
  Well in my case I wrote a little packer / minifier for compiled Jade (http://jade-lang.com/ 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.
  - swah 15y ago
    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)
  - elisee 15y ago
    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 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/ https://github.com/LearnBoost/jadevu/) but the approach is very different.
pbreit 15y ago
Or a hybrid: serve templates/views/html/etc as usual but Ajax straight to the API/db.
lukeholder 15y ago
maybe this: http://news.ycombinator.com/item?id=3200709 http://news.ycombinator.com/item?id=3200709
bobbyi 15y ago
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?
- Vandy_Travis 15y ago
  You could make sure that the requesting page is on your domain.
  - jonprins 15y ago
    It's trivial to use a proxy to modify the referral headers.
- ceol 15y ago
  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?
- k7n4n5t3w4rt 15y ago
  Make the calls to the API over HTTPS.
k7n4n5t3w4rt 15y ago
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/ http://jacksonteece.com/

by aeden 15y ago

elisee 15y ago

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/62agb7qpUNU https://plus.google.com/118077068834135870002/posts/62agb7qp...

leftnode 15y ago
Thanks for the link, I'll check it out.

swah 15y ago

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

elisee 15y ago
Well in my case I wrote a little packer / minifier for compiled Jade (http://jade-lang.com/ 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.
- swah 15y ago
  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)
- elisee 15y ago
  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 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/ https://github.com/LearnBoost/jadevu/) but the approach is very different.

pbreit 15y ago

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

lukeholder 15y ago

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

bobbyi 15y ago

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?

Vandy_Travis 15y ago
You could make sure that the requesting page is on your domain.
- jonprins 15y ago
  It's trivial to use a proxy to modify the referral headers.
ceol 15y ago
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?
k7n4n5t3w4rt 15y ago
Make the calls to the API over HTTPS.

k7n4n5t3w4rt 15y ago

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/ http://jacksonteece.com/