Storage on Vercel (opens in new tab)

Does this mean I have to potentially deal with two vendors when there is an outage? Awesome!

This isn't finalized yet, apologies for the confusion. We'll be updating the pricing for Blob shortly (it's in private beta and invite only). The pricing for KV and Postgres is up to date.

You will get better customer support from Vercel. Cloudflare gives almost zero customer support if you are pay-as-you-go plan.

> That's quite the cost increase for the DX improvement.

It depends how much you spend on egress vs developers.

Hijacking this comment to ask if anyone has had luck integrating Cloudflare R2 with Pleroma.

I’ve not had any luck getting it to work though I’m also not well versed on the terminology.

Will they run my workloads without requiring my attention for decades? I'd love to rewrite and move some old PHP sites from my webhost, but that one has been hosting them without requiring my attention for probably close to 15 years. I'm a little skeptical these fancy cloud runtimes will even exist a few years from now.

Classic VC-backed B2B play. The trick, however, is finding a "wedge" people actually want on its own. Unfortunately that seems to be easier said than done.

> now my defacto playbook for building lasting bottom up disruptive cloud companies

What companies have you built (or played a role in building) using this "playbook" that fit your description?

Cloudflare own and run the services they’re offering whereas it looks like Vercal storage is just other people’s services rebranded

I believe this is a core factor as to why Supabase hasn't joined Cloudflare and Vercel, they don't have that "outside" aspect. By all other counts, they are well established to do so and who knows maybe they do have something in the works to tie in their offerings together from the "outside".

> https://twitter.com/swyx/status/1417136897894326277

Companies are leasing out the core aspects of computing (storage, networking, CPU, GPU, auth), nothing really insightful here. Just your average day in capitalism.

> many other platforms try to start off offering everything under the sun

Do they? Or do they also start small, then build up over the years until they have everything under the sun, rinsing and repeating the process.

I'm right with you. This stuff was exciting like ~5 years ago. I did several projects with Firebase functions as well as Lambda. Randomly on a few of my projects, the functions don't work anymore. Although I haven't touched it in like 4 years.

Either way, I'm back on the monolith train and probably won't look back for a while.

This, feels to me like the opposite shift is happening. People moving away from microservices and going back to the monolithic arch because they realized they don’t need the scale and complexity FAANG is working on.

We have been there too. We feel so much happier after abandoning microservices in our previous product. I also wrote a post about it: “where did the microsservice go”(https://zenstack.dev/blog/microservice)

This managed to encapsulate something that has been in the tip of my tongue ever since I first encountered them. That company is just a sea of red flags to me.

> It preys on inexperienced engineers

For a weekend/side project that needs db and storage, why would I spend days correctly setting up, securing, and provisioning all my infra when I could just pay a little extra and never worry about it?

When creating a new project I wear all hats. Project management, UX/UI designing, Frontend, Backend, Infra, User testing, security.

Having to maintain multiple projects that all bring income in as a solo developer wearing all the hats is very time consuming, this is an absolute godsend and I'll pay for the DX happily.

Its extremely expensive, and I'm aware of two companies migrating away from NextJS itself (neither were ever hosting with Vercel, though).

I've only talked in depth with one of them, but the reason is complexity: they want "a react framework" and every update to NextJS substantially raises the complexity bar, introducing a large number of features that they don't want or need. There's also been at least one incident of a NextJS bug which only affected non-Vercel deployments; and that incident came up in this discussion as evidence for their concern that NextJS doesn't have a future outside of Vercel (the company and the platform).

I had the same experience. I have a Next.js app and Postgres DB I host on a server-ful PaaS. I hosted the same app on Vercel with Neon DB and the app was significantly slower. The first time Neon is connected, it will be slow so I was prepared for that. Consequent reloads and using the app normally was slow too. Maybe integrating Neon directly with Vercel will fix these issues.

I just don’t see the value prop to use Vercel for SaaS apps. Using a running server for those works better, cheaper, and faster. For consumer-facing storefronts, Vercel is a no-brainer though.

This is why at Xata we have developed our own ORM-like SDK for TypeScript and we store migration files in the repo. The SDK is very lightweight so it runs in any serverless runtime. It also means we can create DB branches on the fly for each PR, with whatever schema is in the repo, and when the PR is merged, the `main` branch gets migrated automatically.

With frontend a lot of what engineers are tasked to make (highly interactive websites that still have decent SEO and time to FMP), you need to add some complexity to achieve that. SSR + hydration for web apps has been common for years because it's great for SEO and getting a fast paint and because of that we now have these super established hybrid (as in client side and server side rendered) frameworks. Sure you can implement these sites with an html file and some JS to populate it with data, but it's hardly a nice and *easily maintainable* experience when dealing with non-trivial applications.

And now that your app is using one of these frameworks, you probably need some sort of API for whatever. There's a lot to be said about designing a REST api just being exporting an JS function in a file in a /api folder or whatever. If you are already using a hosted option for these frameworks it's an incredibly simple solution that doesn't require to you mess around creating a new project, making a docker image, going to a different cloud provider and giving them your credit card, etc. And depending on your scale that might genuinely be cheaper than running a container 24/7 on a public cloud.

This whole new dx based industry is because sub par JavaScript developers who write bloated electron apps have flooded the market. Nobody wants to come out and say this but that's the truth. Measuring costs are not part of their mindset when it comes to either memory usage or billing. So they can be charged overpriced rates as long as there is a big button which says deploy.

Yes their DX is technically “over complicating basic things to extract money from chump developers” but it lets users just write code and automate away everything else with couple of click.

It limiting your options can be a good thing, people can just ship instead of being stuck in analysis paralysis forever.

I also found it quite nice entry point for newbie developers. I’ve been donating my time to help out new developers, and learning deployment (it isn’t ”basic” for complete newbies) on top of everything can be daunting. Vercel lets them deploy for free and effortlessly so that they can show off what they’ve learned.

That being said, I personally wouldn’t touch Vercel for any serious work either.

Do you deploy just the JS to a CDN or a whole website? I wanted to do something similar, throw a static website on a CDN and use a Go API as its backend. But unsure how to get around CORS in a reliable way.

KV/Postgres are accurate, that Blob page sneaked in. Blob pricing should be figured out shortly, we'll update that page (it's in private beta, invite only currently).

I'm also noting a generic pattern of intermittent response times in pretty much anything serverless.

When you take a traditional tech stack, say LAMP on a dedicated server, performance is very constant overall. You even develop a type of muscle memory for it and adapt a click pace/flow when you use an application like that intensely.

No so much with cloud-native serverless. A page may respond fast and then 10 times slower the next time. There's just so many moving parts (virtualization, edge, cache, cold/warm compute, out of network dependencies, etc) that it feels random to a user.

It's funny that on one hand people are preaching about Time To First Byte and SSR and what not, and on the other people from CF/Vercel and others are massively investing into serverless which almost by definition has to have drastically degraded latency compared to normal apps.

Consumers have always been willing to pay a premium for simplicity & convenience. No difference here: devs will pay for DX.

I mean, you can say that for serverless in general. Heck, you can say that for AWS etc as well.

Yes! Any postgres and redis client will just work. And the blob store has a REST API.

Can you elaborate on your issues with Neon? Interested to know

You mean the KV? Fly had a Redis service but they shut it down. Although tbh it's trivial to add Redis to a Fly app with Docker.

I would guess for people who want Redis? As I recall Cloudflare KV is more limited and wouldn't be a suitable drop-in replacement.

Doesn't Cloudflare KV have to be used with Cloudflare Workers?

Upstash on Fly.io is not serverless. You provision the RAM + connection counts you want, and then pay for that capacity.

This is not what all our customers want, but it is much cheaper to run this way for most fullstack frameworks. It's not ideal for a Redis you don't use at all, though.

We're considering a serverless / metered billing option for this. But what we have is much closer to spinning up a permanent Redis. :)

Usage-based pricing in the cloud is a blessing and a curse. To take best advantage of it you need a third party tool. At least, this is the thesis behind my current employer (https://vantage.sh).

I want to disagree but thanks be to the lack of agreed definitions I will agree.

I don't think you understand what the code is doing. That's a string templating function, not a raw templated string. `${formData.get('name')}` will get passed as a parameter in a var-arg, not stuck straight into the string.