> 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.
(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: render.com
Scaled: vercel
It was a thing in the past too. It's how almost all a CGI and PHP sites worked.
2. That has nothing to do with serverless or servers.
- 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.
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.
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.
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.
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.
I don't understand this. Can't you have a AWS lambda run on a timer, for example?
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.
[0] https://developers.cloudflare.com/workers/learning/using-dur...
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.
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.
1. That's extra cost and complexity and it's still a dedicated server.
2. If it's a min scaling of 1, 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.
1. Having your APIs as lambdas now means you can't simply connect to a Postgres/MySQL without setting up a dedicated server that serve as a connection pool. So you're now "serverless" but you now have to add a server as a connection pool. /facepalm
2. Putting your APIs on the edge means absolutely nothing if your Postgres/MySQL/Redis/3rd party services is still in one location.
3. Serverless edge databases started popping up but they were significantly more expensive (because you have to replicate data everywhere) and more complicated with limited upside.
4. Cold starts on lambda APIs meant that your web app/web site often load slower than a centralized server.
5. You can't reliably share APIs between your web app and mobile app anymore. Previously, a single server could easily be made to serve both your web app and mobile app.
6. Serverless is often more expensive and unpredictable when it comes to billing. Previously, if you paid $15 for a server, you're going to be billed for $15.
7. Serverless is significantly more complicated when you're just trying to build an MVP. There's no need to try to scale like you're Google when you're just trying to create a proof of concept.
8. It made docker worklows harder.
Serverless should not have been the default option for webapps. Serverless should have been the exotic option for companies that had a special scaling/edge need. Instead, servers should still be the default. The problem is that Next.js is so popular and so intertwined with Vercel that serverless is the default now.
If Vercel/Next.js were honest, they would tell everyone to use serverless only if they're making a static website. Everything else should start out as a server.