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

We Need To Talk About Vercel

maxcountryman.com

Post reply on HN
Print view View original

11–20 of 161 posts

Re: We Need To Talk About Vercel

#11

Post by leerob »

llambda wrote: post #10
leerob wrote: post #3

[Lee from Vercel] Max reached out to me today (Sunday) after this experience, and I worked with him this evening get to a resolution for his site on the Vercel free tier. I'm really sorry we weren't able to get to a resolution faster. I've concluded it's not an issue with the Vercel Edge Network based on the reproduction he provided and pushed documentation and example updates (see below). I know Max spent a lot of t…

Actually I reached out to you asking for a comment which I could add to the article, not for your technical support. I was surprised and I have to admit a bit dismayed to watch you throw yourself into the fray on a Sunday. The technical issues, which in fact persist, are at this point an aside to the way Vercel has handled this issue.

You can reference this comment for the article if you'd like. I'm always more than happy to help out folks. Based on all of the information you've provided, everything is working as expected. As I mentioned above, I'm happy to continue investigating if there is a new repro showing unexpected behavior. Thanks Max

Re: We Need To Talk About Vercel

#12

Post by detaro »

leerob wrote: post #3

[Lee from Vercel] Max reached out to me today (Sunday) after this experience, and I worked with him this evening get to a resolution for his site on the Vercel free tier. I'm really sorry we weren't able to get to a resolution faster. I've concluded it's not an issue with the Vercel Edge Network based on the reproduction he provided and pushed documentation and example updates (see below). I know Max spent a lot of t…

> The article states that to update SWR `cache-control` headers you need to use the `headers` property of `vercel.json`[3]. This is for changing the headers of static assets, not Vercel Function responses (Serverless or Edge Functions).

Then why does [3] say "This example configures custom response headers for static files, Serverless Functions, and a wildcard that matches all routes.", if it isn't for changing the headers on Serverless Functions? (EDIT: my bet would've been that its adding the headers outgoing from the CDN, not from the function, but your claim above contradicts that too)

Re: We Need To Talk About Vercel

#13

Post by oefrha »

Slightly related: Netlify has/had an even bigger problem around caching, and not just caching.

I set `cache-control: public,max-age=2592000,immutable` on my SPAs' assets as they're hashed and should be immutable.

But Netlify somehow doesn't atomically swap in a new version: say my index.html referenced /assets/index.12345678.js before and is updated to reference /assets/index.87654321.js instead, there's a split second where Netlify could serve the new index.html referencing /assets/index.87654321.js, while /assets/index.87654321.js returns 404! So users accessing the site in that split second may get a broken site. Worse still, the assets directory is covered by the _headers rule adding the immutable, 30-day cache-control header, and Netlify will even add it to the 404 response... The result is user's page is broken indefinitely until I push out a new build (possibly bricking another set of users) or they clear the cache, which isn't something the average joe should be expected to do.

I ended up having to write a generator program to manually expand /assets/* in _headers to one rule for each file after every build. And users still get a broken page from time to time, but at least they can refresh to fix it. It really sucks.

Re: We Need To Talk About Vercel

#14

Post by preommr »

Vercel scares the hell out of me - their previous handling of that runaway bill of 6k was atrociuos. They basically blamed the user and only handled it after it gained traction on social media.

Beyond that, they do a lot of things with web, while having very little moat as a company. By that I mean they're involved in a lot of front-end libraries, articles, projects, etc. a lot of which they incorporate into their platform. Which is why everyone praises them for their ease-of-use, but anybody should know that there's a reckoning that comes after the honeymoon period when all this has to be maintained. And that stuff gets to be very expensive.

Which would be fine if they were Google with a really wide moat but they're not. They're a thin layer above the big three cloud providers. It's too easy for a dev to just pack up and move to AWS where they're not paying for the overhead once the project becomes serious. It also doesn't help that they're not seen as a serious solution because of things like their poor customer service.

Re: We Need To Talk About Vercel

#15

Post by leerob »

detaro wrote: post #12
leerob wrote: post #3

[Lee from Vercel] Max reached out to me today (Sunday) after this experience, and I worked with him this evening get to a resolution for his site on the Vercel free tier. I'm really sorry we weren't able to get to a resolution faster. I've concluded it's not an issue with the Vercel Edge Network based on the reproduction he provided and pushed documentation and example updates (see below). I know Max spent a lot of t…

> The article states that to update SWR `cache-control` headers you need to use the `headers` property of `vercel.json`[3]. This is for changing the headers of static assets, not Vercel Function responses (Serverless or Edge Functions). Then why does [3] say "This example configures custom response headers for static files, Serverless Functions, and a wildcard that matches all routes.", if it isn't for changing the h…

That should be more clear! I'll update, thank you. Basically, you should always use the framework or "product native" way of adding caching headers. For Serverless Functions (that use Node.js), that's the `response.setHeader()` API[1]. For Edge Functions (that use Web APIs), that's using the Web Response API and passing a headers object[2].

Most of the time folks using Vercel aren't actually using these Functions manually, but instead having framework-defined infrastructure[3] that generates the functions based on their framework-native code (e.g. `getServerSideProps` in Next.js)

[1]: https://vercel.com/docs/concepts/functions/serverless-functi...

[2]: https://vercel.com/docs/concepts/functions/edge-functions/ed...

[3]: https://vercel.com/blog/framework-defined-infrastructure

Re: We Need To Talk About Vercel

#16

Post by ezekg »

This type of behavior, where a CDN flat out ignores a header you’ve set in favor of their own values, without any indication, is incredibly frustrating.

I hit a similar issue when using Cloudflare and the Date header, where I was signing some parts of the response including the Date header. The problem was that if the request hit Cloudflare at just the right^W wrong time, the signature would be invalidated because their Date header value would be different than the original.

They didn’t see it as an issue, even though IIRC the HTTP spec states that a proxy server must not overwrite the Date header if it was set by a prior actor.

Took days of debugging to determine why some requests were producing invalid signatures.

Re: We Need To Talk About Vercel

#17

Post by rektide »

compumike wrote: post #4

> Most of remotejobs.org is already hosted on a VPS and so in my case I'll move the web pieces there with a CDN like Cloudflare in front of it. You probably don’t even need a CDN at all.

Having someone handle multiple points of presence is a nice courtesy to users. Not sweating about outages is worth a lot. Someone else handling botnets & DDoS is fantastic.

I very very much believe in some DIY & doing things ourselves but I also recognize a ton of value in using CDNs. Glad both are options. DIY is hard.

Re: We Need To Talk About Vercel

#18

Post by adrr »

compumike wrote: post #4

> Most of remotejobs.org is already hosted on a VPS and so in my case I'll move the web pieces there with a CDN like Cloudflare in front of it. You probably don’t even need a CDN at all.

Remote Jobs seems to be a content driven site. Why wouldn't it want all that content on the edge?

Re: We Need To Talk About Vercel

#19

Post by Rauchg »

The gist is (which the support engineer referred to as the internal RFC): instead of stripping `cache-control` `s-maxage` / `stale-while-revalidate` values, we should support Targeted HTTP Cache Control[1] (i.e.: `cdn-cache-control` and `vercel-cache-control`).

Vercel strips them because (1) at the time this RFC didn't exist and (2) most of the time you we found customers don't want to cache on the browser side or proxying CDNs, which makes purging and reasoning about cache staleness very difficult.

Another example there is the default `cache-control: public, max-age=0, must-revalidate`. Without that, browsers have very unintuitive caching behavior for dynamic pages.

Customers want to deploy and see their changes instantly. They want to their customers "go to our blog to see the news" and not have to second guess or fear the latest content will be there.

I appreciate Max's feedback and we'll continue to improve the platform.

[1] https://httpwg.org/specs/rfc9213.html

Re: We Need To Talk About Vercel

#20

Post by klabb3 »

rektide wrote: post #17
compumike wrote: post #4

> Most of remotejobs.org is already hosted on a VPS and so in my case I'll move the web pieces there with a CDN like Cloudflare in front of it. You probably don’t even need a CDN at all.

Having someone handle multiple points of presence is a nice courtesy to users. Not sweating about outages is worth a lot. Someone else handling botnets & DDoS is fantastic. I very very much believe in some DIY & doing things ourselves but I also recognize a ton of value in using CDNs. Glad both are options. DIY is hard.

A cdn is largely a value prop to reduce latency for static web pages, so that someone coming from a link get a page load asap. Once you have a dynamic or hybrid app, the value diminishes rather quickly, I assume. Potentially it could become negative if you have different points of failures and cache inconsistencies.
Post reply on HN