4 ms·

> Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interf

> Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interface get pulled down and rendered. A lot of that is likely because of the way most REST APIs are laid out. Suppose you're looking at a page that displays an invoice for an accounting system. With a traditional non-SPA app, you'd do a bunch of SQL queries and build a page from an HTML template. With a REST API, you're doing one HTTP call per entity, at least, and then subsequent HTTP calls for aggregate entities. When I've made SPAs before, I've often eschewed REST and just made a single Ajax call for "everything I need to display X to the user," not just out of efficiency, but also out of laziness -- it's easy to build. As long as you internally use your API only and don't publish keys for third parties, it's easy to maintain too. There are some solutions to address the whole problem on a grander scale (GraphQL comes to mind), but overall, that's the cause of slow SPAs in my experience.

smacktoward 8y ago
Yes, this has been my suspicion too. Calls out across a network like the Internet are always going to perform variably, and each new call you make represents a new roll of the dice on how fast you're going to get a response back. So passing the whole page over the wire in one call feels faster than breaking it up into X calls and then assembling the results of them all on the client end, with the page seeming slower as the value of X gets bigger.
Svenskunganka 8y ago
If that's the case, shouldn't HTTP/2 have solved that issue? HTTP/2 is multiplexed, so if you make something like 10 HTTP calls, only a single TCP connection would be established. Additionally, according to section 9.1 of the HTTP/2 spec[0], connections are persistent so unless the server closed the connection, an already established connection will be available from when you first loaded the page. [0]: https://httpwg.org/specs/rfc7540.html#rfc.section.9.1 https://httpwg.org/specs/rfc7540.html#rfc.section.9.1
- bouncing 8y ago
  Well, no. For one, the most major http client library (Axios) doesn't have support for that kind of pipelining. But also, you don't necessarily know what to pipeline until you get the first request through. Most web apps will make a REST request, look at the contents of the response, then make another REST request. Maybe you could keep the socket open through that, or you could even use websockets to bypass HTTP altogether and use jsonrpc, but still, you don't know what you need to fetch in the second round until you finish the first one, so either way you're looking at a waterfall of requests, one after another. Pipelining them would scarcely help. What would help is having one API request that basically says, "here's who I am and here's the page the user wants. Give me everything for it." Then you're moving the controller back to the server, and leaving only the view on the client.
  - Svenskunganka 8y ago
    Axios doesn't control what protocol is used, the browser and the server will negotitate a suitable protocol and version, which the browser will transparently use for XHR (which Axios use under the hood). Don't confuse multiplexing with pipelining which was introduced in HTTP/1.1. Multiplexing is a much better solution than pipelining to counter head-of-line blocking, since large or slow responses will delay subsequent requests while multiplexing allows parallel response/request communication. I do agree that waterfall-style requests are more prominent with a REST structure, and that something like GraphQL could solve that - but GraphQL seems largely incompatible with how many develop web apps today; smaller components that request their own data. I'm also unsure how compatible a dynamic query language like GraphQL is with denormalized databases like Cassandra or ScyllaDB where you can't model your data before you've established what queries your site/app will perform. I've yet to see a codebase where the REST waterfall problem is a huge problem though. Note that I too dislike how slow websites are these days, and much prefer to both build and use an entirely server-side rendered one. None of the SPAs that I know of has been a success in terms of performance; Facebook, Google Mail, Reddit's redesign, Youtube, Twitch - most of them are dreadfully slow and sluggish.

smacktoward 8y ago

Yes, this has been my suspicion too. Calls out across a network like the Internet are always going to perform variably, and each new call you make represents a new roll of the dice on how fast you're going to get a response back. So passing the whole page over the wire in one call feels faster than breaking it up into X calls and then assembling the results of them all on the client end, with the page seeming slower as the value of X gets bigger.

Svenskunganka 8y ago

If that's the case, shouldn't HTTP/2 have solved that issue? HTTP/2 is multiplexed, so if you make something like 10 HTTP calls, only a single TCP connection would be established. Additionally, according to section 9.1 of the HTTP/2 spec[0], connections are persistent so unless the server closed the connection, an already established connection will be available from when you first loaded the page. [0]: https://httpwg.org/specs/rfc7540.html#rfc.section.9.1 https://httpwg.org/specs/rfc7540.html#rfc.section.9.1

bouncing 8y ago
Well, no. For one, the most major http client library (Axios) doesn't have support for that kind of pipelining. But also, you don't necessarily know what to pipeline until you get the first request through. Most web apps will make a REST request, look at the contents of the response, then make another REST request. Maybe you could keep the socket open through that, or you could even use websockets to bypass HTTP altogether and use jsonrpc, but still, you don't know what you need to fetch in the second round until you finish the first one, so either way you're looking at a waterfall of requests, one after another. Pipelining them would scarcely help. What would help is having one API request that basically says, "here's who I am and here's the page the user wants. Give me everything for it." Then you're moving the controller back to the server, and leaving only the view on the client.
- Svenskunganka 8y ago
  Axios doesn't control what protocol is used, the browser and the server will negotitate a suitable protocol and version, which the browser will transparently use for XHR (which Axios use under the hood). Don't confuse multiplexing with pipelining which was introduced in HTTP/1.1. Multiplexing is a much better solution than pipelining to counter head-of-line blocking, since large or slow responses will delay subsequent requests while multiplexing allows parallel response/request communication. I do agree that waterfall-style requests are more prominent with a REST structure, and that something like GraphQL could solve that - but GraphQL seems largely incompatible with how many develop web apps today; smaller components that request their own data. I'm also unsure how compatible a dynamic query language like GraphQL is with denormalized databases like Cassandra or ScyllaDB where you can't model your data before you've established what queries your site/app will perform. I've yet to see a codebase where the REST waterfall problem is a huge problem though. Note that I too dislike how slow websites are these days, and much prefer to both build and use an entirely server-side rendered one. None of the SPAs that I know of has been a success in terms of performance; Facebook, Google Mail, Reddit's redesign, Youtube, Twitch - most of them are dreadfully slow and sluggish.