[douglasmoore]

Just want to comment on the first two points as a vercel fan

(1) pooling becomes the solution very early. You get massive speed benefits by keeping a connection open. Hitting connection limits is too easy without it. I feel like a push towards pooling is fine because it has great benefits for scale, speed and reliability. Services like Supabase have connection pooled postgres by default even in their free tier.

(2) nextjs server side data fetching is an amazing feature that deserves it's place in future of web development (the react team agrees since they've added server components). Grabbing data before reaching the client is amazing. If you have a centralized db all the more reason to grab as much as you can in one trip.

Other than that I can agree. I think the advice should generally be to not ever recommend a framework too early or without including its use case.

Current recommendations for the different tiers:

Static: GitHub/cloudflare pages

Server-lite: render.com

Serverless: vercel

[charcircuit]

>nextjs server side data fetching is an amazing feature that deserves it's place in future of web development

It was a thing in the past too. It's how almost all a CGI and PHP sites worked.

[hughesjj]

And jsp and asp and literally everything before ajax

[senttoschool]

1. If you have a server, it’s trivial to setup a connection pool. For example, most Postres clients like Knex or Prisma sets a connection pool for you on your server. There’s no need to setup an external connection pool. It’s good that Supabase does it for you but most managed Postres databases don’t.

In fact, it's trivial to setup many things on a server that you simply can't on a serverless function. For example, a simple cron job or a simple persistent queue or websockets. You have to use 3rd party services for these simple tasks that you could have done on your server.

2. That has nothing to do with serverless or servers.