3 ms·

Your second paragraph essentially is creating a little mini browser, and you have to make sure to get every detail right or you’re back to the uncanny valley of

Your second paragraph essentially is creating a little mini browser, and you have to make sure to get every detail right or you’re back to the uncanny valley of SPA web pages. Performance can even be worse with SPA “page” navigation if multiple round trips are needed for the data on the next page. SPA’s should be used web apps (think slack or Asana), and stick to sever rendered for web pages.

slaymaker1907 4y ago
I think you've highlighted a big problem with SPAs in that they can encourage multiple API calls per user action. IMO, you should probably have a single endpoint per thing a user might do that might combine several conceptual APIs. i.e., if you have an API to add something to a list, have that API also return the current list.
- BFLpL0QNek 4y ago
  I see this in most single page apps. They have a waterfall of multiple API requests by the browser to display a single page. That means the front end has a bunch of logic to aggregate and piece together requests. This in itself isn’t a big deal, if you move to doing it on the backend you still have the same logic and need to make the same sub requests. Where it does become problematic is it leads to fat API endpoints sending far more data to the client than is needed. GraphQL lets you choose what fields you query but odds are there’s still data available you can ask for that shouldn’t be asked for and sent to a browser. If your requests/aggregations are done serverside it gives you a better chance of filtering out data that should never be accessible in the browser. You can also make full use of Cache-Control headers and backend caching. Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend.
  - slaymaker1907 4y ago
    Multiple queries from the frontend is still not great because the latency is much higher than doing at the server all else being equal.
  - KRAKRISMOTT 4y ago
    > Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend. Not true, individual endpoints requires more work for client side optimizations but the CRUD query mapping effort is not reduced with graphql. If anything, graphql endpoints require more effort on the backend side to build because of having to wire up the resolvers unless you are using something like Hasura.
EGreg 4y ago
Is this an SPA? Or is it MPA? https://intercoin.app https://intercoin.app When you refresh, the server renders some of it.
chrismorgan 4y ago
> and you have to make sure to get every detail right or you’re back to the uncanny valley of SPA web pages You can’t get every detail right, because the browser doesn’t expose some of the pieces that would be required to do so—even apart from details that vary between browsers. The most obvious example of unexposed functionality is the loading indicator, but there are more around things like slow or failing networks.
xmonkee 4y ago
> SPA’s should be used web apps (think slack or Asana), and stick to sever rendered for web pages Everyone seems to agree on this, but if this is the case than i’m very confused why this is still a debate. The vast majority of developers are making apps, not “pages”. Pages are useful for a handful of well understood applications that already use CMS systems (blogs, ecommerce, forums etc). So why are we all pushing for MPAs instead of better apps?

slaymaker1907 4y ago

I think you've highlighted a big problem with SPAs in that they can encourage multiple API calls per user action. IMO, you should probably have a single endpoint per thing a user might do that might combine several conceptual APIs. i.e., if you have an API to add something to a list, have that API also return the current list.

BFLpL0QNek 4y ago
I see this in most single page apps. They have a waterfall of multiple API requests by the browser to display a single page. That means the front end has a bunch of logic to aggregate and piece together requests. This in itself isn’t a big deal, if you move to doing it on the backend you still have the same logic and need to make the same sub requests. Where it does become problematic is it leads to fat API endpoints sending far more data to the client than is needed. GraphQL lets you choose what fields you query but odds are there’s still data available you can ask for that shouldn’t be asked for and sent to a browser. If your requests/aggregations are done serverside it gives you a better chance of filtering out data that should never be accessible in the browser. You can also make full use of Cache-Control headers and backend caching. Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend.
- slaymaker1907 4y ago
  Multiple queries from the frontend is still not great because the latency is much higher than doing at the server all else being equal.
- KRAKRISMOTT 4y ago
  > Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend. Not true, individual endpoints requires more work for client side optimizations but the CRUD query mapping effort is not reduced with graphql. If anything, graphql endpoints require more effort on the backend side to build because of having to wire up the resolvers unless you are using something like Hasura.

EGreg 4y ago

Is this an SPA? Or is it MPA? https://intercoin.app https://intercoin.app When you refresh, the server renders some of it.

chrismorgan 4y ago

> and you have to make sure to get every detail right or you’re back to the uncanny valley of SPA web pages You can’t get every detail right, because the browser doesn’t expose some of the pieces that would be required to do so—even apart from details that vary between browsers. The most obvious example of unexposed functionality is the loading indicator, but there are more around things like slow or failing networks.

xmonkee 4y ago

> SPA’s should be used web apps (think slack or Asana), and stick to sever rendered for web pages Everyone seems to agree on this, but if this is the case than i’m very confused why this is still a debate. The vast majority of developers are making apps, not “pages”. Pages are useful for a handful of well understood applications that already use CMS systems (blogs, ecommerce, forums etc). So why are we all pushing for MPAs instead of better apps?