Vercel Edge Middleware: Dynamic at the speed of static | Hacker News Reader

Vercel Edge Middleware: Dynamic at the speed of static

vercel.com

113 pointsleerob48 comments

I like Vercel but if you have more than 10 devs on your team you have to be upgraded to enterprise which when my company asked for a quote we received an increase for 15 devs from what pro would have been. It was from $300 to $3000 a month!

We just wanted to use vercel for hosting and previews but after the quote we ended up going with aws amplify.

If you're looking for a good Vercel alternative running on your AWS account+ preview environments for your backend you can take a look at Qovery.

Disclaimer I am a co-founder

Ran into the same thing - shame it's hidden away under a tooltip on the pricing page.

I don't get it. We run a production headless workload on Vercel and it is slower, has fewer features, yet is more complex and expensive than traditional LAMP server stacks.

Hey there, sorry about this experience. Would love to help investigate – want to send me an email (lee at vercel dot com)?

Your hustle is bonkers Lee. Content, engagement, etc. Much respect

It’s called progress.

I chuckled. 10/10.

Vercel let us get rid of our LAMP stack. No more sys admin or dev ops or updates or Docker or PHP debugger or VMs to maintain.

Just the frontend to write, plus a headless CMS. Freed up sooooo much dev time. You no longer need backend devs or devops for simpler sites.

.. a traditional LAMP stack is not in any way comparable to what Vercel (and other similar services) offer.

We don't use Vercel either for it is slower and offers less functionality than competitors but comparing the general concept to a LAMP stack is definitely not valid.

Curious what you use instead and what features you use that Vercel doesn’t have.

AWS Amplify and Firebase

However I have to admit that we don't necessarily run the "target" applications that Vercel was really designed for. We have a full suite of Lambda backend services that communicate with each other in VPCs and over SQS. We have scheduled executions using CloudFront and listen to events happening in several other AWS subservices.

Now, we also have two "simpler" React applications that we have actually test-driven on Vercel before, but the cold start time of functions was honestly quite horrible and detrimental in comparison, and the problem that really drove us away very quickly was the lack of integrated database and authentication solutions (e.g. AWS Amplify/DynamoDB/Cognito and Firebase/Firestore/Auth). I know about Railway and 0auth, but we have no interest in using several different providers with uncertain confidence in them just for basic application logic, especially because they don't integrate back into Vercel at all (like e.g. functions being called when a DB record changes) and seem to be more expensive than even AWS itself.

If Vercel was more like a "Heroku for serverless", and at the very least offered some of these basic features directly, and then had some good ways of connecting them together, we would potentially reconsider.

Still waiting for the long-promised *non*-Next.js examples, though:

https://github.com/vercel/examples/tree/main/edge-functions

:-/

Here's an example with SvelteKit[1]. You can put a middleware.ts (or.js) in the root folder of any framework and it will work. We also have examples for using Edge API Routes, which work with any framework[2].

[1]: https://github.com/vercel/examples/pull/320

[2]: https://github.com/vercel/examples/tree/main/edge-api-routes

Hi!!! `vercel/examples` maintainer here. We have some with Svelte and plain edge examples, but more importantly, what would you like to see?

okbel, thanks for the reply. I am interested in translating a Cloudflare Worker (and I know that's the tech underneath Vercel Edge Functions, as leerob indicated last year) that, on my site on Cloudflare Pages, manipulates headers for assets-caching and a Content Security Policy. This is framework-agnostic — I've used it with Hugo, Eleventy, and Astro. Thus, any headers-related examples which *don't* start with `import { NextResponse } from 'next/server'` would be very helpful. :-D Again, thanks, and congratulations on today's launch to GA.

Would an example with a custom CSP be useful ?

guibibeau, that would help, too (although I presume it still would come under the subject of HTTP headers). In short: *any* examples that *don't* require any part of Next.js --- or any other specific framework --- would be what a number of us have wanted since last fall's announcement. Thanks!

That's a nice use-case with HashiCorp and complying with country-specific regulations.

Vercel is all proprietary/closedsource right, just Next.js is opensource right? Truly asking/wondering, not making a statement or trying to attack, just getting clarity?

I ask because I work on VA.gov which requires FedRamped SaaS and PaaS OR on-premise installs and I don't think Vercel has either but we could use some parts of Vercel as on-prem if there were a paid on-prem support system.

VA.gov right now is a static build system (Metalsmith + Liquid templates) stored in an S3 bucket that we are working on moving to Next.js.

Here are the open source repos that make up VA.gov:

https://github.com/department-of-veterans-affairs/content-bu...

https://github.com/department-of-veterans-affairs/vets-websi...

https://github.com/department-of-veterans-affairs/va.gov-cms

Yes, the open source Next.js doesn't include support for deploying middleware to the edge. If you run `next start` it runs middleware in the main server process. I work at Netlify and to support running Next middleware on edge functions we had to write our own open source integration for it, just as we did for deploying Next to lambda functions.

As someone who has never used serverless functions before..

Netlify functions are based on AWS lambda functions, which spin up a container with say a node.js runtime environment everytime a request (or another event) comes in, then executes the user provided node.js function within the runtime. I can imagine that handy for something like cronjobs or api requests which happen occasionally.

But using Netlify functions for things like Next.js SSR (or API routes) means, that for every single website request, a new container is setup, the function is run once, and the container is discarded. Am i right in this? Isn't that a huge overhead in contrast to a long running server process?

(Netlify engineer here) To echo what the others have said, lambdas are a bit smarter than that. They actually keep the node process running until it has been idle for around 5-15 minutes. We can make use of that ourselves by reusing the Next server too. We even cache data locally in the lambda tmpdir (though we do that more for Gatsby). The cold start issue though is one of the reasons that using isolates rather than Node-based functions is so great. Both Cloudflare Workers (used by Vercel) and Deno Deploy (used by Netlify) have extremely fast starts, even when cold.

It's generally just a better fit for this model, which is why I'm so glad to see the approach becoming more popular and am genuinely please that Vercel's offering has gone GA. The more this model of edge computing spreads, the better. More framworks will add support, and it will be a virtuous cycle. The WinterCG work on creating a common standard for these runtimes is also a great project.

Read up on isolates. Really interesting stuff! It indeed seems to be a better and more natural fit for something like SSR route handlers, as far as i understand it.

> More framworks will add support, and it will be a virtuous cycle.

I'm in the early phase of developing a SSG in (TypeScript) Node currently. I think i'll study isolates and Deno a bit more, before going further. :)

V8 Isolates aren't exactly new (been around for about a decade); I'm sure the good folks at Netlify are up to speed on them. :)

Containers were clearly the safer bet when FaaS options hit the scene 6-8 years ago. Now with WASM opening up possibilities, Cloudflare made the smart move to base their edge compute off isolates, given the significantly reduced overhead.

Will be fun to see how the cloud competition responds!

I think they meant "I read up on isolates", rather than "You should read up on isolates"! I think you're exactly right though. Isolates are the way forward, and are gradually going to take more and more use cases from node-based functions.

Right, that's what i meant.

Take a look at our docs on integrating with Netlify Edge Functions. They're mainly aimed at framework developers. https://docs.netlify.com/netlify-labs/experimental-features/...

Thank you!

Vercel has edge function support as well that will work with any framework, docs are here: https://vercel.com/docs/build-output-api/v3#vercel-primitive...

Thank You, too!

Vercel uses AWS lambda under the hood as well, so it's probably comparable. AWS lambda is a bit smarter than what you said, it keeps containers around for some time able to respond to more requests. There's also concurrency, so if there's a lot of requests it'll keep a lot of containers running to deal with them, and then spin them down as the concurrent requests stop. The exact details are AWS secret sauce AFAIK, but Vercel claim in their docs that under 1% of requests get a cold start which is where a container needs to be setup to handle that request. https://vercel.com/support/articles/how-can-i-improve-server...

Disclaimer: Chief Architect @ Vercel

This is a good summary. Edge Functions bring another set of trade-offs into the mix:

- Startup-time so fast that if you hit a "cold start" it is still fast enough from a human perception (often <30ms attributable to startup)

- Global by default

- Cheaper on a per invocation

- No limits on concurrent invocations

BUT

- Restricted API set, no node.js API support like Buffers or filesystem access

- Smaller max binary size

- Lower available CPU quota per request

- Lower max RAM usage

- Lower CPU-

Congrats on GA! I'd add to the pros that these edge runtime are a lot more standards-compliant than Node too.

Users do get conufused about the CPU quota thing. They compare the 10ms or so that you get with edge functions, vs 10 seconds on lambda and think it's loads worse, without realising they're comparing apples and oranges. Both Cloudflare and Deno Deploy are limiting CPU time, whereas Lambdas are limited on wall clock time. I've had no trouble keeping long-running Deno Deploy functions running for far longer than a Lambda could run, e.g. when using Server-Sent Events or passing-through a large file download. As long as they're blocking on IO rather than CPU then you're fine. As long as you're not doing something like trying to process images, you're much more likely to hit a 10s lambda timeout than a 10ms CLoudflare or Deno limit.

What you're describing is the cold start[1] request lifecycle for Lambda functions. But if a successive request comes soon thereafter, there's a faster warm start path, which is significantly quicker (~ <100ms).

There's also a way to "provision"[2] resources to ensure that the function always stays warm, but that adds to the fixed cost, which is otherwise, near zero, if there are no requests.

[1]: https://aws.amazon.com/blogs/compute/operating-lambda-perfor... [2]: https://aws.amazon.com/blogs/aws/new-provisioned-concurrency...

Okay, thank you guys. I think it's quite hard to estimate, weather using it is a good idea, ux/cost ratio wise.

> Vercel is all proprietary/closedsource right, just Next.js is opensource right? Truly asking/wondering, not making a statement or trying to attack, just getting clarity?

Based on vercel.com/oss, it appears that most bits of the Vercel PaaS are closed source, and I don't see an on-premises hosting option. Vercel also doesn't appear in FedRAMP Marketplace search.

Can someone explain this for a non-JavaScript node dev?

You push your code and only god knows where it runs but cheaper and more webscale.

And I'm not sure about the cheaper.

It’s a bit more expensive but only god knows where it runs*

Vercel is fairly clear about where it runs your code - depending on the type of page/deployment its going to be either S3, Lambda, or a cloudflare edge worker. There is a ton of logic behind how deployments work but the general benefit of using a service like Vercel is basically exactly as described above -- you push your code and it just works and you don't worry about it.

This is an attractive prospect for a lot of folks who want to spend their time making their apps better and not building/monitoring infrastructure. However, there are some folks who really like to build and maintain their own infra and in that case a service like Vercel might not be the best fit.

How do I use a database with a Vercel app?

Hey! you can check out some of the database integrations that we have here: https://vercel.com/integrations#databases

Excited to finally use this!

Would be really appreciated if they would enable their free plan to be used for "commercial" sites. Their definition of a commercial-purpose site is so expansive it precludes just about every site I need to stand up. I know they deserve to make money, but Cloudflare, Netlifly, Heroku, etc. all offer this, so makes it hard to justify not just using one of them.

Surely a commercial website should bring in enough to cover Vercel's $20/month plan?

Their definition seems fairly reasonable to me.

Reply on news.ycombinator.com