4 ms·

This is probably stupid (I'm not a web developer), but how about using Javascript on the (human, in a web browser) client side to convert API results into DOM e

by unwind 13y ago

This is probably stupid (I'm not a web developer), but how about using Javascript on the (human, in a web browser) client side to convert API results into DOM elements? It would probably be less than fun to write and maintain such a monster, but it would at least make it possible to expose a single API from the server's point of view ... Yay?

jheriko 13y ago
you could also do the opposite... the machine version can parse the HTML. despite the myths to the contrary this is extremely easy since the various bits of the web stack which are poorly implemented don't really cause an issue if you just want to extract text content, especially if you control the form of it (e.g. you could use class or id to identify data). it is after all a markup language and this is exactly what it is meant for (the web browser does this...)
- icebraining 13y ago
  And if you want a standard way of enriching your HTML for machine reading, there's RDFa (as well as microformats and microdata).
Nilzor 13y ago
I think you didn't catch the author's definition of an API: If the machine and the human can access the same resource on the same URI - it's one API. Don't need to convert the Json on the client side - it can be done on the server side whenever a client specifies that it wants the resource returned as application/json in the HTTP header.
steveklabnik 13y ago
You're not stupid, you're going to see a lot more of that in the future. Users of the HAL media type (built on top of JSON) have built something that does exactly this. Here's FoxyCart: https://api-sandbox.foxycart.com/hal-browser/hal_browser.html https://api-sandbox.foxycart.com/hal-browser/hal_browser.htm... I was literally about to open up my editor and start working on one for http://jsonapi.org http://jsonapi.org , but then I decided to check HN first instead. ;)
jnbiche 13y ago
If you're just referring to building an API and then consuming it to build your client-side web site, then it's not stupid at all -- this is called "API first" architecture and more and more developers are using this approach. (myself included)[0]. The only tricky part with this approach for small-scale sites is getting authentication right. REST architecture is fundamentally stateless, which means it's tricky to implement a "Remember Me" checkbox. The simplest way around this (which does involve saving state server-side on the DB) is to issue a nonce once the user authenticates via whatever means you want, and then using that nonce to authenticate each request until the user logs out or a specific period of time passes. All of this assumes you're serving everything over HTTPS, of course. Anyway, if you do it right, it's no less difficult to maintain than anything else. Since all of your DOM interactions are client-side, this means you end up with a large JS application, but tooling is getting better, and JS isn't a bad language to work in (however, I am actively looking into both Dart and Typescript as more robust alternatives). 0. http://www.leaseweblabs.com/2013/10/api-first-architecture-fat-vs-thin-server-debate/ http://www.leaseweblabs.com/2013/10/api-first-architecture-f...
- marrs 13y ago
  That's not the only tricky part with this approach. Pages take ages to load because all rendering has to be done in the browser and can't be cached. The site completely breaks when JS isn't enabled, which discounts search engines and users who disable JS (whether you like it or not, some users do this). It's a brittle solution to a rare problem. Isomorphic Javascript should be able to give the best of both worlds. I've been playing with Meteor and Derby recently. Of the two, Derby seems like the closest to what I'd want from a modern web framework.
  - steveklabnik 13y ago
    Client-side rendering can often be _faster_. See sites like Bustle, for example, which is an Ember app that's super speedy. I'm not sure what you mean by "can't be cached." See http://www.reddit.com/r/webdev/comments/1kf84d/bustlecoms_speed/cboc81f http://www.reddit.com/r/webdev/comments/1kf84d/bustlecoms_sp... for more. Less than 1% of users have JavaScript disabled. Search engines don't care about pretty, so it's pretty easy to render just some data inside a NoScript tag.
acdha 13y ago
This is not at all stupid: in fact, it can make a ton of sense for sites where the content changes quickly because you can have the browser cache the framework code for a long period of time so the page loads quickly and then your server only needs to deliver small amounts of current data rather than a large collection of HTML which mostly hasn't changed. This is particularly nice for news sites when the headlines are the same even if there's one part of the page which is customized for your account. The catch is that search engines won't see any of that content unless you provide an alternative. Some places use the same API but either run the JavaScript on the browser or in a separate server process to avoid this.
angersock 13y ago
You can even go so far as to write a web server that queries your API and renders static HTML to clients--which is what we did at my last startup. This sort of thing is referred to as a Service-Oriented-Architecture. It's a great way to sandbox a lot of stupid--you setup a little Sinatra app to be a fake API server while your buddy builds out the real backend, and one day you flip a switch and everything comes to life correctly. (j/k that doesnt happen everything is always terrible the first time)

by unwind 13y ago

jheriko 13y ago

you could also do the opposite... the machine version can parse the HTML. despite the myths to the contrary this is extremely easy since the various bits of the web stack which are poorly implemented don't really cause an issue if you just want to extract text content, especially if you control the form of it (e.g. you could use class or id to identify data). it is after all a markup language and this is exactly what it is meant for (the web browser does this...)

icebraining 13y ago
And if you want a standard way of enriching your HTML for machine reading, there's RDFa (as well as microformats and microdata).

Nilzor 13y ago

I think you didn't catch the author's definition of an API: If the machine and the human can access the same resource on the same URI - it's one API. Don't need to convert the Json on the client side - it can be done on the server side whenever a client specifies that it wants the resource returned as application/json in the HTTP header.

steveklabnik 13y ago

You're not stupid, you're going to see a lot more of that in the future. Users of the HAL media type (built on top of JSON) have built something that does exactly this. Here's FoxyCart: https://api-sandbox.foxycart.com/hal-browser/hal_browser.html https://api-sandbox.foxycart.com/hal-browser/hal_browser.htm... I was literally about to open up my editor and start working on one for http://jsonapi.org http://jsonapi.org , but then I decided to check HN first instead. ;)

jnbiche 13y ago

If you're just referring to building an API and then consuming it to build your client-side web site, then it's not stupid at all -- this is called "API first" architecture and more and more developers are using this approach. (myself included)[0]. The only tricky part with this approach for small-scale sites is getting authentication right. REST architecture is fundamentally stateless, which means it's tricky to implement a "Remember Me" checkbox. The simplest way around this (which does involve saving state server-side on the DB) is to issue a nonce once the user authenticates via whatever means you want, and then using that nonce to authenticate each request until the user logs out or a specific period of time passes. All of this assumes you're serving everything over HTTPS, of course. Anyway, if you do it right, it's no less difficult to maintain than anything else. Since all of your DOM interactions are client-side, this means you end up with a large JS application, but tooling is getting better, and JS isn't a bad language to work in (however, I am actively looking into both Dart and Typescript as more robust alternatives). 0. http://www.leaseweblabs.com/2013/10/api-first-architecture-fat-vs-thin-server-debate/ http://www.leaseweblabs.com/2013/10/api-first-architecture-f...

marrs 13y ago
That's not the only tricky part with this approach. Pages take ages to load because all rendering has to be done in the browser and can't be cached. The site completely breaks when JS isn't enabled, which discounts search engines and users who disable JS (whether you like it or not, some users do this). It's a brittle solution to a rare problem. Isomorphic Javascript should be able to give the best of both worlds. I've been playing with Meteor and Derby recently. Of the two, Derby seems like the closest to what I'd want from a modern web framework.
- steveklabnik 13y ago
  Client-side rendering can often be _faster_. See sites like Bustle, for example, which is an Ember app that's super speedy. I'm not sure what you mean by "can't be cached." See http://www.reddit.com/r/webdev/comments/1kf84d/bustlecoms_speed/cboc81f http://www.reddit.com/r/webdev/comments/1kf84d/bustlecoms_sp... for more. Less than 1% of users have JavaScript disabled. Search engines don't care about pretty, so it's pretty easy to render just some data inside a NoScript tag.

acdha 13y ago

This is not at all stupid: in fact, it can make a ton of sense for sites where the content changes quickly because you can have the browser cache the framework code for a long period of time so the page loads quickly and then your server only needs to deliver small amounts of current data rather than a large collection of HTML which mostly hasn't changed. This is particularly nice for news sites when the headlines are the same even if there's one part of the page which is customized for your account. The catch is that search engines won't see any of that content unless you provide an alternative. Some places use the same API but either run the JavaScript on the browser or in a separate server process to avoid this.

angersock 13y ago

You can even go so far as to write a web server that queries your API and renders static HTML to clients--which is what we did at my last startup. This sort of thing is referred to as a Service-Oriented-Architecture. It's a great way to sandbox a lot of stupid--you setup a little Sinatra app to be a fake API server while your buddy builds out the real backend, and one day you flip a switch and everything comes to life correctly. (j/k that doesnt happen everything is always terrible the first time)