[leerob]

[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 time on this with back and forth, so I just want to say again how much I appreciate the feedback and helpfulness by providing a reproduction.

Here are the full details from the investigation:

- Beginning Context: Vercel supports Astro applications (including support for static pages, server-rendered pages, and caching the results of those pages). Further, it supports caching the responses of "API Endpoints" with Astro. It does this by using an adapter[1] that transforms the output of Astro into the Vercel Build Output API[2]. Basically, Astro apps should "just work" when you deploy.

- 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). Instead, you would want to set the headers on the response itself. This code depends on the framework. For Astro, it's `Astro.response.headers.set()`[4]. This correctly sets the response SWR headers.

- Vercel's Edge Network does respect `stale-while-revalidate`, which you can validate here[5] on the example I created based on this investigation. This example is with `s-maxage=10, stale-while-revalidate`. Vercel's Edge strips `s-maxage` and `stale-while-revalidate` from the response. To understand if it's a cache HIT/MISS/STALE, you need to look at `x-vercel-cache`. I appreciate Max's feedback here the docs could be better—I've updated the Vercel docs now to make this more clear[6].

- I've started a conversation with the Astro team to see how we can better document and educate on this behavior. In the meantime, I updated the official Vercel + Astro example to demonstrate using SWR caching headers based on this feedback[7].

- The reproduction provided by Max[8] does not show the reported issue. I was not able to reproduce, which is the same result that our support team saw. It sounds like there were some opportunities for better communication here from our team and I apologize for that. I will chat with them. Free customer or not, I want to help folks have the best experience possible on Vercel. If Max (or anyone else) can reproduce this, I am happy to continue investigating.

[1]: https://docs.astro.build/en/guides/integrations-guide/vercel...

[2]: https://vercel.com/docs/build-output-api/v3

[3]: https://vercel.com/docs/concepts/projects/project-configurat...

[4]: https://docs.astro.build/en/reference/api-reference/#astrore...

[5]: https://astro.vercel.app/ssr-with-swr-caching

[6]: https://vercel.com/docs/concepts/edge-network/caching#server

[7]: https://github.com/vercel/vercel/pull/9778

[8]: https://github.com/maxcountryman/astro-trpc-example

[llambda]

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.

[leerob]

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

[theobr]

It’s pretty clear these issues were beyond what traditional support was capable of. If you had reached out to someone like Lee earlier it’s likely your experience would have been much better

Vercel’s definitely in a weird place, trying to be the home for innovation while also offering more traditional support. While the support experience you had was less than ideal, you’re also failing to recognize that you are bleeding edge a bit here.

Your reply here makes it really hard to take any of what you’ve done in good faith. Lee has been incredible to work with and I commend his efforts here

[llambda]

What a disappointing take.

In fact Lee was looped in six weeks ago; there was an issue with Remix and CDN cache behavior which popped up on GitHub. I mentioned my issues in that thread thinking they were likely related. Lee responded and let me know he would talk to the internal team.[0] However, Lee did nothing that was ever visible to me. Moreover, I completely disagree with your assessment: it should not require Lee or social media posts to tackle issues like this, that’s completely unscalable and not a realistic way to run a business.

It’s pretty irresponsible of you to be suggesting folks reach out directly to Lee when frontline support fails. That sucks for Lee and it’s bad for the Vercel business.

To be blunt with you, your comment does not read well. It looks like you’re ignoring very real problems and doing everything you can to dismiss them as “bad faith” when in fact there’s a demonstrable problem which shouldn’t be excused as growing pains but instead addressed head on. This kind of fanboyism doesn’t help anyone and I hope Vercel takes the time to reflect on this feedback and make real, meaningful changes.

[0]: https://github.com/vercel/community/discussions/1559#discuss...

[tipiirai]

Please note that the above comment is super carefully written, because Vercel puts tremendous efforts into their public image and marketing. However, their real support is terrible, as pointed out in the article.

[detaro]

> 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)

[leerob]

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

[transitivebs]

Hey Lee, Travis here.

One piece of meta feedback for Vercel reading through all this is that whenever you have multiple ways of accomplishing something (like setting headers in vercel.json vs in the handlers themselves), it's bound to cause confusion.

Love Vercel :)