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

41–50 of 161 posts

Re: We Need To Talk About Vercel

#41

Post by getcrunk »

jacooper wrote: post #25
ilrwbwrkhv wrote: post #8

If anyone needs a CDN, please use BunnyCDN. I have tried almost every other major CDN and it just blows everything else out of the water. Regarding Vercel, they do have quite poor support so it doesn't feel rock solid and dependable. They are a great start though, but then ideally you should just switch to bare metal on Hetzner or something when you are earning serious money from your business.

Honestly nothing compares to bandwidth free expenses with cloudflare especially with cloudflare R2. Also having different pricing for every region is very annoying.

Yea but better to not keep all you eggs in one basket and also centralization of web issues re:cf

Re: We Need To Talk About Vercel

#42

Post by transitivebs »

leerob wrote: post #15
detaro wrote: post #12

Earlier quoted context omitted.

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

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

Re: We Need To Talk About Vercel

#44

Post by detaro »

Kevcmk wrote: post #38

Vercel is deceitful. The Image/img fiasco really pulled the covers off for vercel for me. I have migrated all my work off of the platform. NextJS’ lint strategically dissuades you from using the img tag in favor of the NextJS Image component. If you make the mistake of heeding this advice and migrating to it, you can’t use static site generation—which means you are stuck using their hosting. Here’s one of the most PR…

Lol, silently* replacing the original request with the company response instead of documenting it in the docs is certainly a move. Nice to have all the thumbs-up and heart reactions on the "sorry we don't do it", for sure. Love the "We'd love to hear your feedback" and then locking the discussion too. Not having the feature is one thing, but why not properly document that and the (by now existing) workarounds?

* yes, not 100% silent, there is a small gray indicator from Github that it has been edited, but one would not expect a full-on replace with that.

Re: We Need To Talk About Vercel

#45

Post by [deleted] »

transitivebs wrote: post #42
leerob wrote: post #15

Earlier quoted context omitted.

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

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

[deleted]

Re: We Need To Talk About Vercel

#46

Post by locustous »

jacooper wrote: post #25
ilrwbwrkhv wrote: post #8

If anyone needs a CDN, please use BunnyCDN. I have tried almost every other major CDN and it just blows everything else out of the water. Regarding Vercel, they do have quite poor support so it doesn't feel rock solid and dependable. They are a great start though, but then ideally you should just switch to bare metal on Hetzner or something when you are earning serious money from your business.

Honestly nothing compares to bandwidth free expenses with cloudflare especially with cloudflare R2. Also having different pricing for every region is very annoying.

Hetzner is cheaper unless you are serving a sizable asset with R2. R2 costs per call. That cost is more than most web bundle size assets will be at Hetzner egress pricing.

Re: We Need To Talk About Vercel

#47

Post by boundlessdreamz »

jacooper wrote: post #25
ilrwbwrkhv wrote: post #8

If anyone needs a CDN, please use BunnyCDN. I have tried almost every other major CDN and it just blows everything else out of the water. Regarding Vercel, they do have quite poor support so it doesn't feel rock solid and dependable. They are a great start though, but then ideally you should just switch to bare metal on Hetzner or something when you are earning serious money from your business.

Honestly nothing compares to bandwidth free expenses with cloudflare especially with cloudflare R2. Also having different pricing for every region is very annoying.

But cloudflare can only be used safely with R2. If you use it as a CDN for your app, you have to be careful about section 2.8 of their TOS. If your usage is mostly caching a JSON API response, you are technically in violation.

Re: We Need To Talk About Vercel

#48

Post by stevebmark »

Kevcmk wrote: post #38

Vercel is deceitful. The Image/img fiasco really pulled the covers off for vercel for me. I have migrated all my work off of the platform. NextJS’ lint strategically dissuades you from using the img tag in favor of the NextJS Image component. If you make the mistake of heeding this advice and migrating to it, you can’t use static site generation—which means you are stuck using their hosting. Here’s one of the most PR…

[flagged]

Re: We Need To Talk About Vercel

#49

Post by comex »

oefrha wrote: post #13

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

Is the JS file somehow being embedded into index.html on the server side? If not, how do you expect this to be atomic when the user’s browser is making two separate requests (with an arbitrary delay between them)?

Re: We Need To Talk About Vercel

#50

Post by stevebmark »

pizzuh wrote: post #7

For someone looking at switching to Vercel for frontend deployment, this is a bit scary. Granted, CloudFront isn't terribly hard to use. It's nice to have all resources in one place, however, it's probably worth sticking to the more mature products for things like content delivery.

[flagged]
Post reply on HN