4 ms·
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
by ElijahLynn 4y ago
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-build/ https://github.com/department-of-veterans-affairs/content-bu...
https://github.com/department-of-veterans-affairs/vets-website https://github.com/department-of-veterans-affairs/vets-websi...
https://github.com/department-of-veterans-affairs/va.gov-cms https://github.com/department-of-veterans-affairs/va.gov-cms
- CharlesW 4y ago> 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.
- ascorbic 4y agoYes, 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.
- lagrange77 4y agoAs 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?
- mcintyre1994 4y agoVercel 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-serverless-function-lambda-cold-start-performance-on-vercel https://vercel.com/support/articles/how-can-i-improve-server...
- cramforce 4y agoDisclaimer: 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-
- ascorbic 4y agoCongrats 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.