Comment by senttoschool | Hacker News Reader

Comment by senttoschool | Hacker News Reader

Parent Full thread

1. Pooling is trivial to setup with servers. In fact, pretty much all clients like Knex and Prisma does connection pooling by default without an external dedicated server.

2, 3. The promise is that serverless APIs can be deployed on the edge for improved latency. The edge does not matter if your data is centralized. So you're adding complexity without the benefit of speed.

4. One of the most important aspects of any web app is load speed. Sure, you can say that serverless is better for scaling but who cares if your web pages are randomly adding 3-5 seconds to the loading time.

5. Try pointing your mobile app to Vercel's serverless APIs that are built inside Next.js. Makes no sense.

6. The most common way people use serverless for webapps is through Vercel's FaaS or some other similar FaaS. That's what I'm focusing on. Not confused. No, FaaS does not have more predictable pricing than servers.

7. It is. I just outlined why it is. Even if you want a simple cron job or a simple persistent queue, you can't do it with serverless functions.

8. You're building your entire stack on a FaaS like Vercel with Next.js. It's not as easy to switch hosts like using Docker. I don't know if you were doing development during the Zeit V1 days but one of the main criticisms of Vercel and newer versions of Next.js is now it makes it hard to switch hosts. Whereas, being able to switch hosts easily is default in a docker setup.

1. Connection pooling can be set up with dedicated servers, but it doesn't mean that all clients like Knex and Prisma do it by default without an external server. Some clients may handle connection pooling internally, while others require external setup.

2, 3. While serverless APIs deployed on the edge can improve latency, it is not accurate to say that the edge doesn't matter if your data is centralized. The edge can still provide benefits such as reduced network hops and improved response times.

4. Serverless architectures can offer advantages for scaling, but it's important to optimize load speed regardless of the architecture used. Serverless doesn't inherently add 3-5 seconds to loading times.

5. It can make sense to use Vercel's serverless APIs built inside Next.js for mobile apps, depending on the specific requirements and architecture of the application.

6. FaaS pricing can vary based on usage and provider, but it doesn't necessarily have more predictable pricing than using dedicated servers. Both options have their own pricing models and considerations.

7. While serverless functions are useful for many scenarios, there are certain tasks like cron jobs or persistent queues that may not be easily achievable with serverless functions alone. However, there are workarounds and alternative solutions available.

8.Building an entire stack on a FaaS like Vercel with Next.js may have implications for switching hosts compared to a Docker setup. Docker provides portability and flexibility, making it easier to switch hosts, whereas FaaS platforms may have specific dependencies or configurations that require adjustment when migrating.

ChatGPT response?

It definitely has the chatgpt vibes to me. No concrete answers to any of the points, just some generic definitions and re-wording of the OP’s points.

> Even if you want a simple cron job ..., you can't do it with serverless functions.

I don't understand this. Can't you have a AWS lambda run on a timer, for example?

Yea, you can. It's just not as simple. In addition, lambdas have time limits so many longer running cron jobs won't work. How about web sockets? Simple queue? Simple cache?

There are many things that you can quickly and easily do with a server that you'd have to reach for 3rd party services to do with serverless. That adds complexity and cost.

This is why I advocate for servers when you're trying to build a product for the first time and serverless if you have a special need.

That's true. On queues, websockets, etc, it might be worth checking out Cloudflare workers durable objects[0]. I've never had to use them, but I wish I had the chance, as they look like a really interesting building block.

[0] https://developers.cloudflare.com/workers/learning/using-dur...

Reply on news.ycombinator.com