Serverless components within an main infa. make sense - it's an easier way to deploy.
But these 'edge' functions ... what is the advantage of saving a few ms on a transaction?
I understand that we may want standard content pushed out to the edge, but in what situation is it really worth all the added complexity of risk of pushing out functions to the edge, to save a few ms?
This can save hundreds of ms from the response time of the initial HTTP request, which means all of the other page resources will load more quickly too.
It does add some additional complexity, but for large sites and hosting platforms, this can have very significant cost savings. It’s usually way cheaper to serve bytes from Cloudflare’s cache than to serve them from your origin.
Curious what is the use case. You can cache stuff, as detailed in the post, but assuming you have huge variance in page contents per user, I can't see too much use. I must be missing something.
If you are talking about developer point of view, then there is no additional complexity. All the complexity is covered by the underlying platform
> what is the advantage of saving a few ms on a transaction?
one example - if a transaction consists of a few separate sequential transactions, then ms add up and might affect user experience. Also an app might need to issue lots of requests on a page load and taken that there is a limit on parallel requests (6 requests per domain), the advantage might be sensible.
Having said that, I tend to agree that many use cases are not sensible to a few ms advantage
This is only the case if you are using HTTP/1.1: https://stackoverflow.com/a/45583977/11383840
Except you need to do it in a totally new paradigm (serverless) where you can't require any `npm` packages and you can't query your database unless it's over the `fetch()` API.
You just have to introduce a build tool like ncc (https://github.com/vercel/ncc) which will bundle your app into a single JS file.