6 ms·

Is it believed that you'll do less overall compute and bandwidth if you use serverless functions to execute (parts of your) client, in place of sending static b

by nawgz 5y ago

Is it believed that you'll do less overall compute and bandwidth if you use serverless functions to execute (parts of your) client, in place of sending static bundles to the client and letting them execute it? I don't really get SSR. Isn't it more desirable to have more of the compute required to render the client done by the client machinery? I view this both as true in corporate and public web scenarios, surely it's cheaper to let the public render the SPA than it is to render it for them, surely in corporate this takes better advantage of already purchased machines with already installed programs instead of developer cycles wasted to recreate it, and surely it's better to have less server load and deployment complexity in both cases

chrisco255 5y ago
Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently. Then, once loaded, any server-side data needs to be fetched from an API request and injected into the page in the proper place. Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the fully compiled HTML + CSS + JS as one static file. So you have to have some server-side logic regardless if you have the need for server-side data. The small amount of memory and compilation overhead by the server-side rendering function is more than made up for by the time saved on network latency. It's just not a significant amount of computation regardless. Importantly, the server-side is not loading a full DOM into memory before sending it down the pipe. It's just interpolating the resulting HTML/CSS/JS as if it were static after fetching the prerequisite data.
- nawgz 5y ago
  > Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently I see my question was unclear. I did not mean compute/bandwidth "in totality", I meant "in costs that would be invoked by the application owner". > Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the fully compiled HTML + CSS + JS as one static file. Sure, but the first hit would've been a cache hit anyways. > The small amount of memory and compilation overhead by the server-side rendering function is more than made up for by the time saved on network latency I don't really believe network latency would play in here. CDN would have the static bundle "at the edge" already for you. Static content is very easy to serve and break up into cacheable components for clients too, the Edge isn't really a revolution in that space. It's also unfair to present Edge functions as always-hot in terms of latency here, again I imagine the cost invoked for such features must be so high for so little gain
  - presentation 5y ago
    Yes it’s cheaper but also it’s a worse experience. It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same.
    - nawgz 5y ago
      > It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same. Yes, if you pay more money and integrate into cloud vendor systems, you can get more compute. Besides, the person with a crappy android is irrelevant to monetizing your application anyways, so their user experience is pretty irrelevant surely? I don't really understand the idea to spend money to improve the experience for people unlikely to spend money on your thing. And, again, the "beefy cloud server" experiences load from a shared user pool, so I doubt there's just flawless performance waiting for everyone all the time; if there is, surely you see "loss leader" written all over it.
      - presentation 5y ago
        - depending on use case you don’t need to pay much to get these perf benefits (eg caching snapshots on CDNs) - monetization depends on your business. How about B2B where customers are employees using crappy corporate laptops. Not like the only high value customers are using high end computers. - and besides maybe you have ethics and don’t want to lock out people who don’t have the latest high end gear. - flawless isn’t the point, better is the point
  - chrisco255 5y ago
    > Sure, but the first hit would've been a cache hit anyways. Similarly, a serverless function that is "warm" already has all the logic needed to inject the static template into memory. It simply needs to call out to the database, which is physically closer to the server, and always quicker, without the need for an additional HTTP handshake...and then inject the data into the template, before sending it down the wire. > CDN would have the static bundle "at the edge" already for you. The static bundle just saves on download time. The bundle still needs to be loaded into memory on the client to create the Document Object Model that powers every webpage. Depending on how your client-side bundle is structured, it may be 100ms or 1s before it even begins to make the outbound request back to the API to fill in the necessary data to power your BI dashboard or whatever your use case is. And that's if your BI dashboard was structured to be optimal with all requests rolled up into one (additional architectural effort, easier to satisfy on SSR with multiple database hits having less impact to performance). Edge functions like Cloudflare Workers have 0ms cold starts. We're talking tiny fractions of a penny per request. For example, Cloudflare Workers have 100K free requests per day and then its $0.15 / 1 million requests after that. Better user experience, and it might cost you pennies more per month vs. static + round-trip.
tored 5y ago
If you look at it from a societal perspective SSR is better, it is easier to place servers closer to a clean energy source rather than every client.
dbbk 5y ago
Doing something fully on the client is a nice idea, if your users all have fast connections, high processing power, and are all visiting from a desktop instead of a mobile device. As soon as you have anyone visiting on a mobile device, and particularly on a mobile network, it's far superior to render it on the server.
- nawgz 5y ago
  You're right, it's a far superior pattern to waste tons of dev cycles to enable your team to give money to AWS so AWS can execute the logic their device would already do, just so your initial page load is 50% faster and your app otherwise performs identically, except the huge stutter step when you try to hydrate the state to match what your server rendered, which looks like hot garbage. HN is not full of front-ends, I can tell that much.
  - dbbk 5y ago
    Your viewpoint is valid but it's a philosophical argument, not a pragmatic one. I'm also not sure what you mean by 'stutter step'. I would posit that 95% of visitors never even notice hydration.
    - nawgz 5y ago
      > Your viewpoint is valid but it's a philosophical argument, not a pragmatic one. I think not locking yourself to specific cloud architectures is quite pragmatic, but to each their own. > stutter step SSR advocates: parsing JS and interacting takes way too long, it's so noticeable and terrible! Me: so if you serve a pre-rendered-via-SSR page AND a bundle of interactivity, there's going to be a nice set of static content that will be uninteractable during that entire terribly long parsing and loading phase? SSR advocates: Never heard of such a thing, parsing JS and getting interactivity is instant!

by nawgz 5y ago

chrisco255 5y ago

Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently. Then, once loaded, any server-side data needs to be fetched from an API request and injected into the page in the proper place. Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the fully compiled HTML + CSS + JS as one static file. So you have to have some server-side logic regardless if you have the need for server-side data. The small amount of memory and compilation overhead by the server-side rendering function is more than made up for by the time saved on network latency. It's just not a significant amount of computation regardless. Importantly, the server-side is not loading a full DOM into memory before sending it down the pipe. It's just interpolating the resulting HTML/CSS/JS as if it were static after fetching the prerequisite data.

nawgz 5y ago
> Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently I see my question was unclear. I did not mean compute/bandwidth "in totality", I meant "in costs that would be invoked by the application owner". > Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the fully compiled HTML + CSS + JS as one static file. Sure, but the first hit would've been a cache hit anyways. > The small amount of memory and compilation overhead by the server-side rendering function is more than made up for by the time saved on network latency I don't really believe network latency would play in here. CDN would have the static bundle "at the edge" already for you. Static content is very easy to serve and break up into cacheable components for clients too, the Edge isn't really a revolution in that space. It's also unfair to present Edge functions as always-hot in terms of latency here, again I imagine the cost invoked for such features must be so high for so little gain
- presentation 5y ago
  Yes it’s cheaper but also it’s a worse experience. It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same.
  - nawgz 5y ago
    > It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same. Yes, if you pay more money and integrate into cloud vendor systems, you can get more compute. Besides, the person with a crappy android is irrelevant to monetizing your application anyways, so their user experience is pretty irrelevant surely? I don't really understand the idea to spend money to improve the experience for people unlikely to spend money on your thing. And, again, the "beefy cloud server" experiences load from a shared user pool, so I doubt there's just flawless performance waiting for everyone all the time; if there is, surely you see "loss leader" written all over it.
    - presentation 5y ago
      - depending on use case you don’t need to pay much to get these perf benefits (eg caching snapshots on CDNs) - monetization depends on your business. How about B2B where customers are employees using crappy corporate laptops. Not like the only high value customers are using high end computers. - and besides maybe you have ethics and don’t want to lock out people who don’t have the latest high end gear. - flawless isn’t the point, better is the point
- chrisco255 5y ago
  > Sure, but the first hit would've been a cache hit anyways. Similarly, a serverless function that is "warm" already has all the logic needed to inject the static template into memory. It simply needs to call out to the database, which is physically closer to the server, and always quicker, without the need for an additional HTTP handshake...and then inject the data into the template, before sending it down the wire. > CDN would have the static bundle "at the edge" already for you. The static bundle just saves on download time. The bundle still needs to be loaded into memory on the client to create the Document Object Model that powers every webpage. Depending on how your client-side bundle is structured, it may be 100ms or 1s before it even begins to make the outbound request back to the API to fill in the necessary data to power your BI dashboard or whatever your use case is. And that's if your BI dashboard was structured to be optimal with all requests rolled up into one (additional architectural effort, easier to satisfy on SSR with multiple database hits having less impact to performance). Edge functions like Cloudflare Workers have 0ms cold starts. We're talking tiny fractions of a penny per request. For example, Cloudflare Workers have 100K free requests per day and then its $0.15 / 1 million requests after that. Better user experience, and it might cost you pennies more per month vs. static + round-trip.

tored 5y ago

If you look at it from a societal perspective SSR is better, it is easier to place servers closer to a clean energy source rather than every client.

dbbk 5y ago

Doing something fully on the client is a nice idea, if your users all have fast connections, high processing power, and are all visiting from a desktop instead of a mobile device. As soon as you have anyone visiting on a mobile device, and particularly on a mobile network, it's far superior to render it on the server.

nawgz 5y ago
You're right, it's a far superior pattern to waste tons of dev cycles to enable your team to give money to AWS so AWS can execute the logic their device would already do, just so your initial page load is 50% faster and your app otherwise performs identically, except the huge stutter step when you try to hydrate the state to match what your server rendered, which looks like hot garbage. HN is not full of front-ends, I can tell that much.
- dbbk 5y ago
  Your viewpoint is valid but it's a philosophical argument, not a pragmatic one. I'm also not sure what you mean by 'stutter step'. I would posit that 95% of visitors never even notice hydration.
  - nawgz 5y ago
    > Your viewpoint is valid but it's a philosophical argument, not a pragmatic one. I think not locking yourself to specific cloud architectures is quite pragmatic, but to each their own. > stutter step SSR advocates: parsing JS and interacting takes way too long, it's so noticeable and terrible! Me: so if you serve a pre-rendered-via-SSR page AND a bundle of interactivity, there's going to be a nice set of static content that will be uninteractable during that entire terribly long parsing and loading phase? SSR advocates: Never heard of such a thing, parsing JS and getting interactivity is instant!