Hacker News Reader

Of course, but this is just an instance of TFA's key observation:

> Geeks think they're rational beings, while they're completely influenced by buzz, marketing, and their emotions.

To which I want to add 1. that geeks young and old try also to pad their resume and eg use React and under all circumstances whether it's warranted or not (which seems at least rational from a personal career development PoV) 2. geeks think the web is about them, completely and utterly failing to understand that its entire point is easy self-publishing.

As to next.js specifically, it obviously doesn't make sense to tie serverless to React. Also, it doesn't make sense, like at all, to use React for smallish trivial internal web UIs when the main app is written in another backend language and your team has no js coding experience which just invites security nightmares and endless updates, and breaks agility and job rotation for no reason.

As to XML, there's a minor factual misunderstanding here in that DTDs, like XML itself, isn't a genuine inception, but rather a simplification and proper subset of SGML intended for the web where it has failed (even though it sees plenty use outside).

But that should't take away from the main point: that you don't go around advertising your fscking format without checking requirements. In this case, using XML (or SGML and HTML) for something that isn't document data, or conversely, using eg JSON for text documents. Just makes you look like a one trick pony.

All true (I rented a bare metal server myself for my pet projects), but it's still quite tempting.

- scale to zero, or scale to one (no cold starts) - not having to manage disk space - not having to manage quite a bit of security (ssh login, fail2ban, opened ports, unprivileged user) - in some cases, out of the box - or easier - deploy pipeline

Would you feel more or less confortable taking vacations while having a server or a server less platform?

Would you feel more or less confortable undergoing a security assessment while using a server or a server less platform?

I quite agree with what you say but can't deny there are lots of non negligible advantages.

> ssh login, fail2ban, opened ports, unprivileged user

All of these things are extremely trivial to configure.

> Would you feel more or less confortable taking vacations while having a server or a server less platform?

Depends on the SLA of my provider. Most VPS providers have 3+9s these days, then the reliability concern becomes my code, same with serverless.

> Would you feel more or less confortable undergoing a security assessment while using a server or a server less platform?

It is a common misconception that serverless platforms are inherently more secure. In reality, they just have different security concerns. In my eyes, it takes a practitioner of equivalent skill to properly harden a fleet of servers Vs correctly handle the eccentricities of IAM et al in a large cloud app.

Right, I've come to believe that the software development world is led by the nose by snake oil salesmen. Most software developers don't have a range of experience outside of a CS degree, so they easily fall into "this is the new best practice" traps, especially if they look flashy and professional (examples: https://12factor.net https://machalliance.org)

FWIW, after using serverless technologies in both AWS and GCP for years, I think the cloud vendors have largely fixed most of the issues you're complaining about. Few examples:

1. Amazon provides things like RDS Proxy, which is essentially a hosted version of pgbouncer, and Aurora, essentially a "serverless postgres" - no need to manage your own server for connection pooling.

2. Cloud vendors have largely fixed the cold start times through a variety of means like min scaling of 1, warming requests, and functions that can process many requests simultaneously.

3. I don't get your point about not being able to share an API between web and mobile. I do this all the time.

4. When it comes to vendor lock-in, GCP for example offers Cloud Run, which will essentially just spin up any Docker container you give to it.

Managing your own servers can have a huge cost, and this can be an especially large cost for a small team. For example, does your business have any SOC 2 or other compliance requirements? Being on serverless as opposed to being on, say, your own EC2 instances, means a huge amount of work (e.g. ensuring servers are always patched, ensuring they are configured securely, ensuring you have permissions configured correctly, etc.) can be offloaded to the cloud provider, who is frankly much more likely to do it correctly than a small startup team.

If anything, I think GCP's CloudRun is awesome and the real future of serverless. In my mind it has most of the benefits of something like kubernetes with about 1/50th of the complexity.

My main points are Vercel/Next.js focused.

1. That's extra cost and complexity and it's still a dedicated server.

2. If it's a min scaling of 1 and it processes many requests, isn't that just a server?

3. In the context of using APIs written inside Next.js for your mobile application.

4. Sure, Cloud Run is nice. I remember using Docker with Cloud Run as well. But it's a bit different than my main gripe with Next.js/Vercel.

The problem are the business agrements that they are putting in place, like with Sitecore where now Vercel/Next.js are the bless way to do CMS frontends, with .NET being left behind.

So it is either Vercel/Next.js with the out-of-the-box development experience, or DIY integration with other stacks that are also "supported".

And they aren't the only ones following such hype cycle.

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

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

And jsp and asp and literally everything before ajax

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.

Your points do nothing to back up your claim that "serverless architectures are much more complicated compared to servers"

1. You still have to do polling with servers 2. Not a serverless problem 3. Not a serverless problem 4. This is a tradeoff, not complexity 5. Why not? What does serverless have to do with this? 6. Appears you're confusing serverless and FaaS. Regarldess, FaaS has incredibly predictable pricing. Previously if you paid $15 for a server, you're going to be billed for however many servers you had running on average throughout the month. 7. It's not. Your points here are trying to back it up, but have so far not done so. 8. Why would that be? And how does that factor into complexity?

Your claim is flawed for two reasons: 1. Serverless != FaaS. FaaS is serverless, serverless is not FaaS. 2. You've not taken auto-scaling into consideration on the server side.

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