From DHH shunning serverless, Ahrefs saving millions by using a cloud provider at all, to Amazon raining fire on their own serverless product, serverless has recently faced significant scrutiny.

But still, everyone and their pet goldfish seem to be creating a serverless runtime (see Bun, Deno, Pydantic, Cloudflare, Vercel, Serverless, Neon, Planetscale, Xata, FaunaDB, Convex, Supabase, Hasura, Banana, and literally hundreds more). One research paper from Berkeley even claimed:

Serverless computing will become the default computing paradigm of the Cloud Era, largely replacing serverful computing and thereby bringing closure to the Client-Server Era.

-- Cloud Programming Simplified: A Berkeley View on Serverless Computing

Is it all hype? Is there real 100% objective merit to it? Where does serverless excel? Where do the trade-offs make sense?

To understand how developers are receiving serverless, I went to where developers live: Reddit, Twitter, Hacker News, and YouTube. I parsed 1,000s of discussions and synthesized my findings in this article, striving to present only thought-provoking opinions.

Next, I transcribed these discussions onto a whiteboard, organizing them into "Pro Serverless," "Anti Serverless", or "Neutral" categories, and then clustering them into distinct opinions. Each section in this post showcases an opinion while referencing pertinent discussions.

Anti-Serverless Opinions​

Giant software companies such as Shopify, GitHub, and Stack Overflow have achieved new heights using tried-and-true frameworks like Ruby on Rails. However, serverless presents an intriguing new paradigm that promises to reduce costs, accelerate development, and eliminate the need for maintenance. And as with any technological shift, there will always be skeptics.

Opinion: Serverless is a performance and financial hazard​

Key Takeaway 🔑​

One of the most vocal criticisms of serverless computing is the unpredictability of its costs and the latency associated with cold starts. While cloud providers have made significant improvements in optimizing serverless runtimes over time, these issues remain a significant concern for many developers.

Additionally, serverless introduces a new paradigm that brings its own set of challenges when building complex applications, particularly those requiring multiple services to communicate with each other. This is already a common problem with microservices, but serverless further complicates the issue by forcing developers to work within a stateless and I/O-bound compute model.

These latencies can have real financial consequences; Amazon found that every 100ms of latency cost them 1% in sales. Moreover, without proper billing safeguards in place, serverless costs can spiral out of control, potentially leading to the infamous situation of a startup sinking under its cloud bill.

Encountering any of these issues could understandably leave a sour impression and be a compelling reason to abandon serverless in favor of a traditional VPS.

Opinion: Serverless is a fad​

Key Takeaway 🔑​

Serverless is a fad, and the hype will fade.

Kudos to AWS's marketing team, as they successfully persuaded thousands of CTOs to stake their entire technology stack on a contentious new paradigm for building applications.

Some even go as far as to say serverless is "dangerous" or "wrong". In some ways, this viewpoint is not exaggerated. If cloud providers were not striving to lock everyone into their products to capture market share and boost revenue, what kind of corporate entities would they be?

Early adopters and evangelists did a great job at highlighting 10x features and pushing the cloud computing agenda. But always be weary of a technology that necessitates developers to acquire a new set of skills and tools, potentially wasting developer's time in a low-demand technology. Engineering teams should exercise caution when betting the farm on serverless as it may lead to vendor lock-in. When things go wrong, good luck with troubleshooting and refactoring!

At the end of the day, serverless represents a substantial investment that could arguably be better allocated to other aspects of the business. Why not utilize long-running servers that were already deployable and maintainable in the late 2000s.

So, does serverless really solve your problems, or are you just succumbing to the hype?

Pro Serverless Opinions​

Technologies that catch on usually have something good going for them, and serverless is no exception. Despite all the buzz and marketing blitz, there's some real enthusiasm for it. Some companies are saving time and money with serverless, making it a win-win. Some devs think serverless is the new must-have tool in the toolbox.

Opinion: Serverless accelerates the pace of feature development​

Key Takeaway 🔑​

Counter-intuitively, an interesting aspect of serverless computing is that it appeals more to early product development than to enterprise products is the speed at which features can be developed. The virtually negligible time and cost required to provision cloud computing resources make serverless computing particularly attractive to hobbyists for their projects.

During the early stages of building a product, the most critical factor to consider when designing your system is the pace of development. Concerns about scalability fall far behind developer experience, as they are not yet relevant issues. In this context, serverless computing provides a compelling value proposition.

In light of this, why would anyone waste time setting up their own server? Starting with serverless computing is a logical choice. If cost or speed issues arise, other options can be considered at that time.

Opinion: Serverless can be outstanding when implemented correctly​

Key Takeaway 🔑​

For those who have successfully adopted serverless and lived to share their experiences, the enthusiasm is palpable.

It appears that building on serverless from first principles can yield outstanding results. Beyond the marketing hype, the true benefits of serverless become evident. Maybe as the Berkeley researchers predicted, maintaining your own server is becoming a thing of the past. With serverless, you can save money, reduce development time, and cut maintenance costs—a triple win.

Moreover, as serverless offerings like storage, background jobs, and databases continue to improve, the ecosystem will support the construction of increasingly complex apps, while still upholding the promise of serverless.

If you can navigate the downsides of serverless, you can create a product with an infrastructure that feels almost effortless. Perhaps the naysayers' tales are louder than the truth.

Neutral Opinions​

I believe it is crucial to emphasize neutral viewpoints. In my view, these tend to be the most truthful because they recognize the advantages and disadvantages of each approach. They are also the opinions least commonly expressed, as many developers tend to be set in their ways.

Opinion: Serverless offers genuine benefits for specific use cases, but it is often misused or applied inappropriately​

Key Takeaway 🔑​

No technology is a silver bullet, and serverless is no exception.

Every technological decision is about choosing the right tool for the job. Serverless has some distinct trade-offs that need to be understood before it's adopted. Conduct thorough research on compute density, single-responsibility microservices, and performance requirements. Once you do, you'll see that serverless can offer immediate and tangible value. Recognize that serverless is not a replacement, but an alternative.

Whenever you hear someone criticize serverless, be wary of the problems they encountered. Were they design problems? Were there clear misuses of serverless? Serverless is not a panacea.

Conclusion​

The anticlimactic conclusion? As always, it depends.

Though, I am more convinced that developers should strongly consider using serverless during the early stages of their SDLC. I previously built an application exclusively using serverless but was burned by lop-sided unit economics¹. In retrospect, I can attribute that failure to not considering the downsides of serverless before adopting it.

That being said, I have also grown accustomed to Render for fast-paced development, and so far, I have no complaints. However, as I am always striving to become a 10x engineer, I will consider adding serverless to my toolbox.

Footnotes​

1. I built a Shopify App that gave shop owners pixel-perfect replays of customers navigating their online store. I stored session data (using rrweb) in S3 and processed events using lambda. I ended up operating at a loss until I shut it down. ↩

Ask any developer: do you prefer GraphQL or REST? This often leads to opinionated conversations, sometimes even devolving into vulgar opinions rather than objective facts.

To delve into the GraphQL vs. REST debate, I scoured platforms where developers frequently discuss such matters: YouTube, Reddit, Twitter, and Hacker News. I parsed 1,000s of discussions and synthesized my findings in this article, striving to present only thought-provoking perspectives.

Next, I transcribed these discussions onto a whiteboard, organizing them into "Pro GraphQL," "Pro REST," or "Neutral" categories, and then clustering them into distinct perspectives. Each section in this post showcases a perspective while referencing pertinent discussions. To conclude, I highlight blog posts from GitHub and Shopify that serve as informative case studies in this ongoing debate.

Pro REST Perspectives​

REST APIs have been around for decades. Much of the world's networking infrastructure is built on the HTTP standard, so it's no surprise that REST enjoys substantial support. However, similar to how SOAP was eventually overtaken by REST, GraphQL now poses a challenge to REST. As with any technological shift, there will always be those who express skepticism.

Perspective: GraphQL is not worth the complication​

Key Takeaway 🔑​

GraphQL is complicated.

A few features that are simple to implement with REST instantly become a huge pain with GraphQL:

• Access control
• Rate limiting
• Caching
• DOS protection
• Using Maps/Tables/Dictionaries
• N + 1 Problem

The complexity that arises from adopting GraphQL can sometimes outweigh its benefits for most engineering teams. Does your organization have a substantial budget allocated for engineers? Is your data model extremely relational? Is your API catering to a vast user base? Do all your engineers possess a proficient understanding of GraphQL? If not, you probably shouldn't be adopting GraphQL for its flexible query language.

Entire companies like Stellate and Apollo were born out of the need to solve these arguably over-complicated characteristics of GraphQL.

Perspective: GraphQL is not an optimization​

Key Takeaway 🔑​

GraphQL is not an automatic performance optimization.

If your team faces similar challenges as Facebook, feel free to focus on optimizing your API layer. Otherwise, there are likely other optimizations you can implement for your application beyond the query layer.

Despite its flexible query language, GraphQL can become a performance bottleneck. Writing a query that slows down your API is quite easy. Tasks like optimized DB queries, precise access control, query complexity analysis, and HTTP-level caching are complex to implement and introduce additional overhead to your server.

GraphQL does not inherently enhance the speed of your API. The responsibility to optimize your API performance still rests on your shoulders.

Pro GraphQL Perspectives​

Despite the naysayers, GraphQL has still captured the minds of thousands of developers. The experiences of using GraphQL are undeniable, and it's easy to see why so many developers are excited about it.

Perspective: GraphQL has an amazing developer experience​

Key Takeaway 🔑​

Developers prioritize developer experience.

Ask any developer you know; developer experience is the key to unlocking productivity. The GraphQL community has undoubtedly prioritized developer experience for users. Check out the abundant and growing ecosystem of tools available for free. I'm impressed with The Guild and their work on building a comprehensive GraphQL suite of tools.

From documentation and client generators to data validation, server implementations, and API gateways, mature open-source projects cover it all. The caveat is that Node.js/JavaScript is the most popular language for GraphQL, resulting in differing levels of support for other languages. However, this situation is rapidly changing.

Because GraphQL mandates the creation of an API schema, unlike REST, code generation stands out as a prominent feature among most GraphQL technology stacks. This significantly benefits developers by reducing the amount of boilerplate code they need to write. The ability to generate code from "front to back" is a game-changer for rapid development. While the REST ecosystem is progressing, it took a back seat for many years until OpenAPI emerged.

Whether in small or large-scale software systems, GraphQL addresses a crucial aspect of the developer experience problem like never before. Personally, I believe this is a significant factor contributing to GraphQL's current traction. The compelling developer experience offered by GraphQL often leads people to overlook the tradeoffs.

Perspective: GraphQL has proven itself in the largest organizations​

You can't ignore the use of GraphQL in hyper-scale organizations like Facebook, GitHub, and Shopify.

There are compelling case studies for the performance of GraphQL in some of the largest engineering organizations in the world. But it's important to note that these organizations have the resources to invest in the infrastructure and engineering talent required to make GraphQL work at scale.

For most organizations, those resources are not available and important to the immediate business goals. In these cases, GraphQL is not the right choice if you are purely looking for an optimization.

That being said, I still feel developer experience is a compelling reason to adopt GraphQL if your team is willing to invest in the learning curve.

Neutral Perspectives​

I think it's important to highlight the neutral perspectives. In my opinion, these are the ones that hold the most truth in that they acknowledge the tradeoffs of each approach. They are also the rarest opinions to find since most developers are stubborn in their ways.

Perspective: GraphQL is great for some use cases, but not all​

Key Takeaway 🔑​

GraphQL proves valuable for intricate relational data models and sizable teams grappling with substantial scalability challenges, but it's not a silver bullet.

GraphQL emerged as a solution to a specific predicament at Facebook: the migration of the social media giant's newsfeed functionality from web to mobile. (Read more about it here).

This perspective may seem apparent and lacking in provocation, yet, as with any engineering choice, trade-offs come into play. Because Facebook has contributed so many great projects to open source, it's easy for engineers to blindly adopt the latest and greatest from Facebook in hopes it will help you preemptively solve scaling problems. But as always, you have to understand the problem you are solving to make the right technical decision for your team or you risk over-engineering your solution.

Perspective: The benefits of GraphQL are great, but difficult to implement in practice​

Key Takeaway 🔑​

To successfully implement GraphQL at scale, a high level of skill is required to ensure optimal performance.

In practice, GraphQL provides an exceptional interface for frontend and API consumers, enabling them to query and explore the API efficiently. However, it does shift a significant portion of complexity to the backend. For instance, in the absence of persisted queries, GraphQL exposes an interface that can be potentially hazardous, allowing unbounded query requests to your API. Have a public GraphQL API? Then you are forced to rate limit by calculating query complexity like Shopify. Without access to skilled engineers and the resources for substantial infrastructure investment, GraphQL can become a recipe for disaster when it comes to scalability.

Nonetheless, when executed correctly, GraphQL can bring immense benefits to client-heavy applications, offering tools like GraphiQL for interactive query exploration, cache normalization with urql for efficient data management, and the ability to create granular queries without much hassle. Without GraphQL, incorporating these features would demand a significant amount of effort.

REST doesn't share these scalability challenges to the same extent, as backend developers can pinpoint performance issues to specific endpoints. Developers can also rely on the mature and well-defined HTTP specification that existing infrastructure is already equipped to handle.

Conclusion​

Before this exercise, I built GraphQL and REST APIs in both toy and production examples and always leaned towards DX. After reading 1,000s of perspectives, I am convinced that you should start with REST to avoid the complications of GraphQL. If you are lucky enough to be making technical decisions at "unicorn scale", I would consider looking at GraphQL to optimize the query interface. Meanwhile, take advantage of the growing OpenAPI ecosystem.

In most cases, for GraphQL to effectively address the problems it was originally designed to solve, a team should ideally possess a considerable number of developers, and their API should handle traffic at a "unicorn scale." Most likely it's not necessary to overly concern yourself with such extensive scalability, as the complexity involved might not be justified. Notable giants like Twilio and Stripe, for instance, have not yet integrated GraphQL into their public APIs despite being well beyond unicorn status.

Nevertheless, if you have a workflow that takes advantage of the remarkable developer experience offered by GraphQL, then by all means, embrace it! Just ensure that you are fully aware of the tradeoffs involved. Ultimately, the most suitable choice for most teams is whatever enables faster development.

Side note: If you are just looking to build fast, checkout tRPC - the DX is pretty awesome. I have no affiliation other than building a production app using tRPC.