Can someone knowledgeable please explain where these workers are useful? 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 t…
I wonder this too, given ultimately, 99% of non-static sites will need to reach out to a central database. So to render a dynamic page, your worker then has to go to the DB, no? 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.
Vercel Serverless Functions vs. Cloudflare Workers
21–30 of 37 posts
Re: Vercel Serverless Functions vs. Cloudflare Workers
#22Earlier quoted context omitted.
It's often not actually more complex, it's simpler. With Cloudflare Workers, for example, you don't think about regions, availability zones, provisioning resources, or cold starts. You just write code, and it can scale from one request per second to thousands without any thought or work on your part, partially because of how its designed and partially because it's scaled across so many locations and machines.
> You just write code 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.
Re: Vercel Serverless Functions vs. Cloudflare Workers
#23Earlier quoted context omitted.
It's a little more complex than that. Naturally an 'always running' server is faster when you're not getting a cache hit or you're running into a Lambda cold start. But for stuff served from CDN cache it won't make any difference. Vercel/nextjs are geared towards encouraging you to make everything static so that it does get served that way. If you need to generate every part of your page to be user-specific then I wo…
Yes I'm sure it's down to the cold start issue of Lambda. Are there any tips on how to keep it warm? I didn't go down the static route as I have tens of thousands of product pages. Will check out the Incremental Static Generation - thanks.
If you were using your own Lambda you could set a minimum reserved concurrency to avoid cold starts, but I don’t think Vercel gives you that level of control. The main thing to do is try to serve as much statically as possible so that it reads straight from the CDN cache or static file store and that way it never hits your Lambda on requests.
With ISR the Lambda updates the rendered file in the background, rather than in response to a request (generally), and the user is just served the last generated render. So in that scenario the Lambda latency is taken out of the equation.
If you know which products are most important you could also render a subset of them at build time and let the fallback handle the long tail ones.
Re: Vercel Serverless Functions vs. Cloudflare Workers
#24Can someone knowledgeable please explain where these workers are useful? 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 t…
I wonder this too, given ultimately, 99% of non-static sites will need to reach out to a central database. So to render a dynamic page, your worker then has to go to the DB, no? 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.
Re: Vercel Serverless Functions vs. Cloudflare Workers
#25Earlier quoted context omitted.
I wonder this too, given ultimately, 99% of non-static sites will need to reach out to a central database. So to render a dynamic page, your worker then has to go to the DB, no? 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.
Why not use a database with a worker? https://www.cloudflare.com/products/workers-kv/
Re: Vercel Serverless Functions vs. Cloudflare Workers
#26Can someone knowledgeable please explain where these workers are useful? 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 t…
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.
Re: Vercel Serverless Functions vs. Cloudflare Workers
#27Wow this was extremely informative for me! Cleared up a cacheing concern I had. Thanks for sharing. I've had good success using the free tier of Vercel functions to handle the low-traffic storefront and user accounts for offsetra.com - Just wrapper functions around stripe and firestore. It's a godsend for independent, unskilled, time-constrained front-end devs like me!
One important piece missing from this article is that on Vercel you do not get global Serverless functions on any plan except the Enterprise plans. By default you can pick one preferred region for your Serverless functions and that's the region that's always used. In practice, assuming you have a somewhat decent caching strategy, this doesn't really matter as far as latency is concerned. Where it could potentially ma…
"Vercel doesn’t replicate Functions across their Network in Free and Pro accounts - Functions can be deployed to one particular region only. Enterprise plan users can specify multiple regions for Serverless Functions."
Re: Vercel Serverless Functions vs. Cloudflare Workers
#28Wow this was extremely informative for me! Cleared up a cacheing concern I had. Thanks for sharing. I've had good success using the free tier of Vercel functions to handle the low-traffic storefront and user accounts for offsetra.com - Just wrapper functions around stripe and firestore. It's a godsend for independent, unskilled, time-constrained front-end devs like me!
One important piece missing from this article is that on Vercel you do not get global Serverless functions on any plan except the Enterprise plans. By default you can pick one preferred region for your Serverless functions and that's the region that's always used. In practice, assuming you have a somewhat decent caching strategy, this doesn't really matter as far as latency is concerned. Where it could potentially ma…
Re: Vercel Serverless Functions vs. Cloudflare Workers
#29Earlier quoted context omitted.
It's often not actually more complex, it's simpler. With Cloudflare Workers, for example, you don't think about regions, availability zones, provisioning resources, or cold starts. You just write code, and it can scale from one request per second to thousands without any thought or work on your part, partially because of how its designed and partially because it's scaled across so many locations and machines.
> You just write code 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.
Re: Vercel Serverless Functions vs. Cloudflare Workers
#30Earlier quoted context omitted.
> You just write code 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.
And you're limited to 50 sub-requests..