3 ms·

Just to take it a step further though, in a world where every browser can run Javascript and make AJAX requests, which of your requirements can't be handled by

by sfeng 12y ago

Just to take it a step further though, in a world where every browser can run Javascript and make AJAX requests, which of your requirements can't be handled by the client communicating with an API directly? Considering sessions for example, local storage is supported by virtually every browser you can name: http://caniuse.com/#feat=namevalue-storage http://caniuse.com/#feat=namevalue-storage In my experience, it's significantly easier to scale an API than a traditional (PHP-style) web server.

michaelmior 12y ago
Why can't sessions be handled by by communicating with an API directly?
- sfeng 12y ago
  Sorry if I was unclear, I was saying sessions _could_ be handled by communicating directly with an API.
sanderjd 12y ago
I don't disagree at all, but scaling a dynamic API is still harder than scaling static resources. Saying "we're doing everything through an API" is one solution to the problem of scaling the dynamic portions of the application, which I alluded to. Something of an aside: You really don't need localStorage to do this. You can still use cookies, you just can't use HttpOnly cookies, and in fact that's what the localStorage polyfills I've used fall back to. The trade-off (drat! there's always one of those) of both localStorage and non-HttpOnly cookies is that it once again becomes easy to steal user access credentials outright if you can manage an XSS attack, which is what HttpOnly cookies helped prevent in theory. On the other hand, in practice XSS attacks can still usually steal an account even with HttpOnly cookies (for instance, by sending a request to change a user's password, which dutifully sends along the valid cookie anyway) or do other nefarious things, so you just can't let XSS happen either way. Another question is: Is the user experience of applications built this way as good? It definitely can be once everything is loaded and churning along, but the initial load can be quite slow and choppy as data comes back piecemeal. Server-rendering the initial page and doing updates through an API is, I believe, the way forward, but it's still tricky and inconvenient to do. And then you once again need to scale the rendering of full pages server-side! tl;dr; Yes, that's a good approach, but not a panacea.

by sfeng 12y ago

michaelmior 12y ago

Why can't sessions be handled by by communicating with an API directly?

sfeng 12y ago
Sorry if I was unclear, I was saying sessions _could_ be handled by communicating directly with an API.

sanderjd 12y ago

I don't disagree at all, but scaling a dynamic API is still harder than scaling static resources. Saying "we're doing everything through an API" is one solution to the problem of scaling the dynamic portions of the application, which I alluded to. Something of an aside: You really don't need localStorage to do this. You can still use cookies, you just can't use HttpOnly cookies, and in fact that's what the localStorage polyfills I've used fall back to. The trade-off (drat! there's always one of those) of both localStorage and non-HttpOnly cookies is that it once again becomes easy to steal user access credentials outright if you can manage an XSS attack, which is what HttpOnly cookies helped prevent in theory. On the other hand, in practice XSS attacks can still usually steal an account even with HttpOnly cookies (for instance, by sending a request to change a user's password, which dutifully sends along the valid cookie anyway) or do other nefarious things, so you just can't let XSS happen either way. Another question is: Is the user experience of applications built this way as good? It definitely can be once everything is loaded and churning along, but the initial load can be quite slow and choppy as data comes back piecemeal. Server-rendering the initial page and doing updates through an API is, I believe, the way forward, but it's still tricky and inconvenient to do. And then you once again need to scale the rendering of full pages server-side! tl;dr; Yes, that's a good approach, but not a panacea.