Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vercel Serverless Functions vs. Cloudflare Workers

moiva.io

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Vercel Serverless Functions vs. Cloudflare Workers

#11

Post by zackbloom »

jariel wrote: post #2

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…

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.

Re: Vercel Serverless Functions vs. Cloudflare Workers

#12

Post by carmen_sandiego »

siquick wrote: post #10

I had been using Vercel for a Next.js SSR deployment up until this week when I moved it to a basic AWS Lightsail box with no real NGINX optimisations. I have Lightsail server in Frankfurt and I am in Sydney and the Lightsail box gets a higher Pagespeed score than the Vercel deployment and from my own anecdotal usage, the page load is noticeably faster. I had Vercel region set to Paris (no Frankfurt region yet). I lov…

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 would say that's a different use case and nextjs isn't necessarily the right tool.

That said, you can actually do some pretty dynamic pages with it. You should try out what they call 'Incremental Static Generation'. It's basically the SWR pattern, but for server-side rendering.

Re: Vercel Serverless Functions vs. Cloudflare Workers

#13

Post by chmod775 »

carmen_sandiego wrote: post #12
siquick wrote: post #10

I had been using Vercel for a Next.js SSR deployment up until this week when I moved it to a basic AWS Lightsail box with no real NGINX optimisations. I have Lightsail server in Frankfurt and I am in Sydney and the Lightsail box gets a higher Pagespeed score than the Vercel deployment and from my own anecdotal usage, the page load is noticeably faster. I had Vercel region set to Paris (no Frankfurt region yet). I lov…

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…

> Vercel/nextjs are geared towards encouraging you to make everything static so that it does get served that way.

That would mean they have no reason to exist. If they're slower than a regular server for dynamic content and only as fast as a regular CDN for static pages, they're beaten by the old server + CDN combination.

The niche for rendering on the edge is really incredibly narrow. Take one step further and you have client-side rendering, take one step back and you're already on a server. I'm not surprised people have trouble finding use-cases, and when they do it often turns out they would've been better served by one of the two other solutions.

Re: Vercel Serverless Functions vs. Cloudflare Workers

#14

Post by carmen_sandiego »

chmod775 wrote: post #13
carmen_sandiego wrote: post #12

Earlier 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…

> Vercel/nextjs are geared towards encouraging you to make everything static so that it does get served that way. That would mean they have no reason to exist. If they're slower than a regular server for dynamic content and only as fast as a regular CDN for static pages, they're beaten by the old server + CDN combination. The niche for rendering on the edge is really incredibly narrow. Take one step further and you h…

I'll have to disagree.

I use Next because it offers SSR plus the hydration step for a fully-fledged React app on client, and the ease with which you can pass stuff between the two. SSR for paint speed and SEO/bots/meta/whatever, and the rich client side app functionality that people expect these days. A traditional server-side-render-only approach doesn't make that as easy, IMO.

I use Vercel for the DX, mostly. I can copy an old project repo and have a fully functioning new project site up in literally 20 mins. Same reason people use Netlify.

Also, they're not necessarily slower for dynamic content. Only noticeably if you hit a cold start really. But that's just the normal serverless/Lambda caveat: in exchange for interventionless scaling, one request in n is a little slower during scale-up events. You can always put your next app on EC2/EB/etc if it worries you. I'm more pro-nextjs than pro-Vercel.

Re: Vercel Serverless Functions vs. Cloudflare Workers

#15

Post by silviogutierrez »

jariel wrote: post #2

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.

Re: Vercel Serverless Functions vs. Cloudflare Workers

#16

Post by MuffinFlavored »

WORMS_EAT_WORMS wrote: post #8

Great post, enjoyed your writing style and drawings a ton! One of the bigger things I think Workers have going for it versus others is it’s ability to bind WASM modules. Hyper efficient, basically native running computation at edge is a really cool concept. Especially since you can talk to it with a dead-simple JavaScript API. For example, Cloudflare charges a good amount of money for image resizing using their CDN h…

> basically native running computation at edge is a really cool concept

What are some real world use cases for this? I'm surprised the Cloudflare product team is prioritizing working on WASM module support instead of like... querying from a database through a way other than `fetch()`.

Re: Vercel Serverless Functions vs. Cloudflare Workers

#17

Post by MuffinFlavored »

zackbloom wrote: post #11
jariel wrote: post #2

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…

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

#19

Post by siquick »

carmen_sandiego wrote: post #12
siquick wrote: post #10

I had been using Vercel for a Next.js SSR deployment up until this week when I moved it to a basic AWS Lightsail box with no real NGINX optimisations. I have Lightsail server in Frankfurt and I am in Sydney and the Lightsail box gets a higher Pagespeed score than the Vercel deployment and from my own anecdotal usage, the page load is noticeably faster. I had Vercel region set to Paris (no Frankfurt region yet). I lov…

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.

Re: Vercel Serverless Functions vs. Cloudflare Workers

#20

Post by jopsen »

andrewbarba wrote: post #9
brendanmc6 wrote: post #3

Wow 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…

If you store data in firestore, dynmodb, postgres or similar.. does it really matter if the function is distributed?
Post reply on HN