DEV Community

Cover image for Still Drowning in API Choices? My Battle-Tested Guide to REST, GraphQL & gRPC
Matheus Julidori
Matheus Julidori

Posted on

2 1 2 1 2

Still Drowning in API Choices? My Battle-Tested Guide to REST, GraphQL & gRPC

TL;DR:

  • REST is the seasoned veteran: simple, widely understood, and a go-to for most standard web applications needing robust CRUD (Create, Read, Update, Delete) operations.
  • GraphQL is the client's best friend: it empowers frontends with incredible flexibility to fetch exactly the data they need, making it a game-changer for complex UIs and data-intensive applications.
  • gRPC is the performance powerhouse: blazing fast and incredibly efficient, it's tailor-made for high-throughput internal microservices and critical real-time systems.
  • The takeaway? There’s no single "best" choice. Each comes with its own set of trade-offs. Your decision should always be guided by your specific use case, performance requirements, your team's expertise, and your existing infrastructure.

When I first dipped my toes into the vast ocean of API design, I'll confess, it felt a bit like navigating a labyrinth. Back in 2020, as a junior developer trying to become a backend specialist, I spent countless days trying to grasp the nuances of REST, GraphQL, and gRPC, poring over documentation, watching tutorials, reading articles, and wrestling with code. For a long time, the pieces just didn't click into place. But then, something shifted. I realized the best way to truly understand these concepts, beyond just memorizing definitions, was to try and teach them myself. That meant diving even deeper, dissecting their architectures, and really internalizing why each exists and where it shines. This article is the fruit of that journey – my attempt to distill years of learning into something clear, practical, and genuinely helpful.


Article Index

  • 1. Understanding the Fundamentals:
    • What is REST? (Representational State Transfer)
    • What is GraphQL? (The Client-Driven Query Language)
    • What is gRPC? (The High-Performance RPC Framework)
  • 2. Deep Dive into Design Choices:
    • Pros & Cons Comparison: A side-by-side look at the advantages and disadvantages.
    • When Should You Use Each? Matching the right tool to the right problem.
  • 3. Practical Considerations:
    • Performance & Scalability: How each style handles load and growth.
    • Hosting & Deployment: Where and how to run your APIs.
    • Community and Ecosystem: The support network behind each style.
    • Tooling, Languages & Frameworks: The ecosystem supporting each.
  • 4. Final Thoughts: My takeaways and advice for your API journey.

What is REST? The Enduring Standard

From my early days exploring web development, REST (Representational State Transfer) quickly became a foundational concept. It’s not a protocol or a framework, but rather an architectural style that has truly stood the test of time since its introduction by Roy Fielding in his 2000 doctoral dissertation. Think of it as the bedrock of how a vast majority of web services communicate.

At its heart, REST leverages the very principles of the web itself. It’s all about managing resources – which could be anything from a user profile to a product in an e-commerce store – identified by unique URLs. To interact with these resources, REST uses the familiar workhorses of the internet: standard HTTP methods like GET (to retrieve), POST (to create), PUT (to update), and DELETE (to remove). This simple mapping makes it incredibly intuitive once you grasp the core idea.

Main Features & Core Concepts:

  • Resource-Based: Everything is treated as a resource, addressable via a unique URL. For me, understanding that a URL wasn't just a path, but the identifier of a specific thing, was a key "aha!" moment.
  • Stateless Operations: Each request from a client to a server must contain all the information needed to understand the request. The server doesn't store any client context between requests. This makes REST APIs incredibly scalable.
  • Uses Standard HTTP Verbs: Relying on GET, POST, PUT, DELETE (and sometimes PATCH) means you're speaking the native language of the web.
  • Responses Typically in JSON (or XML): While not strictly enforced by the style, JSON has become the de facto standard for human-readable and machine-parseable data exchange, though XML was common in earlier days.
  • Cacheable: Resources can be cached by clients or intermediaries, improving performance.
  • Flexible & Language-Agnostic: Because it builds on HTTP, REST isn't tied to any specific programming language or framework. This is one of its biggest strengths, allowing diverse systems to communicate seamlessly.

What is GraphQL? The Client-Driven Query Language

After working with REST for a while, I often found myself frustrated by the "over-fetching" or "under-fetching" problem – getting too much data (and making my app work harder) or not enough (leading to multiple, waterfall requests). Being mainly a backend developer, I still remember the pain of seeing a React page reload 6 times because I didn't know how to avoid reloading them after each one of the 6 API requests I needed to make to fetch all the data. Then I encountered GraphQL, and it felt like a revelation, especially coming from a frontend perspective. Developed by Facebook and open-sourced in 2015, GraphQL isn't just another API style; it's a powerful query language for your API that completely shifts the control dynamic.

My "aha!" moment with GraphQL came when I understood its core promise: it empowers clients to ask for exactly what they need, no more, no less. Instead of the server dictating the data structure for a given endpoint (as in REST), the client specifies the shape of the data it expects. This means you typically interact with a GraphQL API through a single endpoint, sending a flexible query and receiving a predictable, structured response tailor-made for your specific view or component. It's like ordering a custom meal instead of picking from a fixed menu!

Main Features & Why They Matter:

  • Strongly Typed Schema: This is the backbone of GraphQL. The server defines a clear, strongly typed schema that describes all possible data types and operations (queries, mutations, subscriptions). For me, this was a huge confidence booster – knowing exactly what data I could ask for and what shape it would come in.
  • Clients Define Data Shape: This is GraphQL's superpower. Your frontend application sends a query that precisely outlines the data it requires. This directly addresses the over-fetching (getting fields you don't need) and under-fetching (needing multiple requests to get related data) issues common with REST.
  • Single Endpoint for All Operations: Unlike REST's many resource-specific URLs, a GraphQL API typically exposes just one endpoint (e.g., /graphql). All queries and mutations go through this single URL, with the schema determining the logic on the backend.
  • Avoids Over-fetching and Under-fetching: As mentioned, this is one of its primary benefits, leading to more efficient data transfer and often simpler client-side logic.
  • Great for Frontend-Heavy Apps: Because clients have such granular control, GraphQL is particularly well-suited for complex single-page applications (SPAs) or mobile apps that need to fetch diverse, nested data for various UI components.
  • Strong Introspection and Tooling: Tools like GraphQL Playground or GraphiQL leverage the schema to provide auto-completion, real-time error checking, and easy API exploration. This significantly flattens the learning curve once you grasp the basics.
  • Versionless APIs: Since clients request specific fields, adding new fields to the backend doesn't break existing clients, and deprecating old fields can be handled gracefully within the schema, simplifying API versioning.

What is gRPC? The Performance Powerhouse for Microservices

While REST and GraphQL are excellent for many scenarios, especially those involving frontend clients, there's another player that truly shines when raw performance and efficiency are paramount: gRPC (gRPC Remote Procedure Call). I remember first trying to grapple with gRPC early in my career. I got a job that I wasn't even a bit prepared for, working on a Web3 blockchain stack. It was incredibly hard to understand, being nothing like REST. I was let go from that role, and it wasn't until about 4 months ago that I truly grasped its full potential. Created by Google, gRPC is an open-source RPC (Remote Procedure Call) framework designed from the ground up for speed.

The magic behind gRPC's incredible efficiency lies in a couple of key technologies. First, it leverages HTTP/2 for its transport layer, which enables features like multiplexing (multiple requests over a single connection) and header compression. Second, and perhaps most crucially, it uses Protocol Buffers (protobuf) for data serialization. Unlike JSON, which is human-readable, protobuf serializes data into a compact, binary format. This combination makes gRPC truly "blazing fast" and incredibly efficient, especially for inter-service communication where every millisecond and byte counts.

Main Features & Why It's a Game-Changer:

  • Binary Protocol via HTTP/2: This is the foundation of its speed. HTTP/2 offers significant performance benefits over HTTP/1.1, and the binary nature of Protobuf payloads means much smaller message sizes compared to text-based formats like JSON or XML.
  • Contract-First API (via .proto files): With gRPC, you define your service interface and the structure of your messages using .proto files. From these definitions, gRPC generates client and server code in numerous languages. This "contract-first" approach ensures strict typing and consistency across your services, which I found invaluable for maintaining large, distributed systems.
  • Supports Streaming and Real-time: gRPC natively supports different types of streaming (unary, server streaming, client streaming, and bi-directional streaming). This makes it incredibly powerful for real-time applications, live updates, or long-lived connections – scenarios where traditional REST falls short.
  • Strong Client-Server Typing: Because code is generated from .proto definitions, both client and server automatically get strongly typed objects and methods. This significantly reduces runtime errors and makes development more robust, a massive benefit in complex backend architectures.
  • Extremely Fast and Compact: This is gRPC's headline feature. Its efficiency is unmatched for inter-service communication, making it ideal for the backbone of large microservice architectures.
  • Language-Agnostic with Robust Tooling: Despite its complexity, gRPC provides excellent tooling and supports code generation for a wide array of programming languages, allowing polyglot microservice environments to communicate seamlessly.

Pros & Cons: A Side-by-Side Comparison

Now that we've explored each API style individually, let's lay out their strengths and weaknesses side-by-side. This table distills the core trade-offs I've encountered, helping you quickly identify which style aligns best with your project's priorities.

Feature REST GraphQL gRPC
Maturity & Adoption High: Battle-tested, oldest, vast community. Medium: Growing rapidly, strong modern ecosystem. Medium: Gaining traction, especially in enterprise.
Learning Curve Low: Simple, intuitive, builds on HTTP basics. Medium: New concepts (schema, queries, resolvers). High: Binary protocols, .proto files, code generation.
Flexibility Low (Client-side): Fixed responses, over/under-fetching. High (Client-side): Client defines data shape. Medium (Server-side): Strict contracts, but powerful streaming.
Data Fetching Fixed payloads, often requires multiple requests. Precise data fetching in a single request. Extremely efficient binary payloads.
Schema Required No (by default): Less strict, less predictable. Yes: Strongly typed schema for validation. Yes: .proto files define contracts.
Performance Medium: Text-based JSON, multiple requests. Medium: Efficient fetching, but complex queries can be heavy. Very High: Binary, HTTP/2, ideal for high-throughput.
Human Readability Excellent: JSON is clear, URLs are semantic. Excellent: Queries are readable JSON-like syntax. Poor: Binary format, requires tooling to inspect.
Caching Easy: Leverages HTTP caching mechanisms. Difficult: Single endpoint, complex queries. Difficult: Binary, streaming nature.
Browser Support Native: Works seamlessly in all browsers. Native: Standard HTTP POST. Partial: Often needs gRPC-Web proxy.
Tooling & Ecosystem Excellent: Mature, vast libraries, debug tools. Excellent: Strong tools (Playground), active community. Good: Code generation, but debugging tools less common.
Versioning Can be challenging (e.g., /v1/, /v2/). More flexible (add fields, deprecate gracefully). Strong typing aids compatibility.
Complexity Simple to start, scales well for common CRUD. More backend complexity for resolvers. Higher initial setup, more specialized knowledge.

When Should You Use Each? Choosing Your API Style

With the landscape of API styles clearer, the practical question becomes: "Which one should I pick for my project?" Based on my journey through these architectures, I've found that the best choice almost always hinges on your specific use case, team expertise, and performance demands. Here's a breakdown of common scenarios and the API style that typically shines brightest.

Use Case Best Pick My Reasoning / Why It Shines Here
Public-Facing API for Standard CRUD REST Simplicity & Broad Adoption: REST is the most universally understood and easiest to get started with. For typical operations like fetching lists of resources, creating new ones, or simple updates, its straightforward HTTP mapping is hard to beat. Its maturity means vast tooling and community support.
Mobile or SPA with Complex UIs GraphQL Client Empowerment & Efficiency: When your frontend needs to fetch diverse, nested, or highly specific data for multiple UI components, GraphQL prevents the dreaded over/under-fetching. It gives frontend developers unparalleled control, leading to fewer requests and a smoother user experience.
Internal Microservices Communication gRPC Blazing Fast & Efficient: For communication between services within your backend system, where low latency and high throughput are critical, gRPC is the clear winner. Its binary nature and HTTP/2 foundation make it exceptionally performant, ideal for the demanding backbone of a microservice architecture.
Real-time or Streaming Services gRPC Native Streaming Support: If your application requires real-time updates, bi-directional communication, or long-lived connections (e.g., chat applications, live dashboards, IoT data streams), gRPC's built-in streaming capabilities are a game-changer.
Strong Schema Enforcement Needed GraphQL / gRPC Contract-First Design: Both provide a strong contract (schema for GraphQL, .proto files for gRPC) that enforces data types and structures. This is invaluable for preventing bugs and ensuring consistency in large, distributed teams or complex applications.
Team Unfamiliar with Schema Tools REST Lower Learning Curve: If your team is new to API development or lacks experience with schema definition languages and code generation, REST's familiarity with HTTP methods and JSON payloads makes it a much gentler entry point.
High-Performance, Low-Latency Systems gRPC Optimized for Speed: For scenarios where every millisecond counts, such as critical backend services, financial trading systems, or IoT sensor data ingestion, gRPC's binary protocol and HTTP/2 optimizations deliver unmatched speed and efficiency.

Performance & Scalability & Hosting & Deployment

Beyond features and use cases, the practical realities of how your API performs under load and where it lives are paramount. My journey has shown me that while an API style might be perfect on paper, its real-world implications for performance, scalability, and deployment can make or break a project. Let's look at these critical factors.

Performance & Scalability

When it comes to how your API handles traffic and grows with your application, each style presents distinct characteristics.

  • REST:
    • Performance: REST is generally reliable, but because it relies on text-based JSON (which can be verbose) and often requires multiple round trips for complex data, it might not be the most performant choice for low-bandwidth environments or scenarios demanding extreme speed. Each GET request, for instance, comes with standard HTTP overhead.
    • Scalability: Highly scalable due to its stateless nature. You can easily distribute requests across many servers, and caching mechanisms (thanks to HTTP standards) significantly reduce server load.
  • GraphQL:
    • Performance: GraphQL can be incredibly efficient in terms of data fetched per request, drastically reducing "over-fetching." However, performance can degrade if complex queries are poorly optimized on the backend, as a single query can potentially trigger many database lookups. It's efficient data-wise, but needs careful implementation for computation-wise efficiency.
    • Scalability: Scalable, but the single endpoint means you need robust backend infrastructure to handle complex query parsing and resolution efficiently. Caching can also be trickier than with REST, as queries are dynamic.
  • gRPC:
    • Performance: This is where gRPC truly shines. With its binary Protocol Buffers and HTTP/2 underlying transport, it offers unparalleled speed and efficiency. Message sizes are significantly smaller, and HTTP/2 features like multiplexing mean fewer connections and less overhead. It's built for high-throughput, low-latency scenarios.
    • Scalability: Extremely scalable. Its design is perfect for internal microservice communication where efficiency across many services is key. The lightweight nature of messages and efficient connection handling make it ideal for massive distributed systems.

Hosting & Deployment Options

Bringing your chosen API style to life requires careful consideration of where and how it will be hosted. Each has its own ecosystem and requirements.

  • REST:
    • Hosting: Extremely versatile. REST APIs can be hosted virtually anywhere you can run a web server. Whether it's a simple Node.js Express app, a Django REST Framework project, a Ruby on Rails API, or a Spring Boot service, standard HTTP servers are all you need.
    • Deployment: Easy to deploy to common cloud platforms like Heroku, AWS EC2/Lambda, Google Cloud Run, Vercel (for serverless functions), or even a basic VPS. Its ubiquity makes deployment straightforward.
  • GraphQL:
    • Hosting: Requires a GraphQL server implementation (e.g., Apollo Server for Node.js, Graphene for Python, Hasura for instant GraphQL APIs). While these are backend services, they still run on standard web servers.
    • Deployment: Can be deployed to the same platforms as REST APIs (AWS, GCP, Azure, Vercel, etc.), as they typically run over HTTP POST. The main difference is the specific server-side library or framework you'll use.
  • gRPC:
    • Hosting: Has more specific requirements due to its reliance on HTTP/2. It needs an HTTP/2-enabled server and environment. While many modern languages and frameworks have excellent gRPC libraries (Go, Node.js, Java, Rust, Python's grpcio), you need to ensure your hosting environment properly supports HTTP/2.
    • Deployment: Often best suited for cloud environments that provide robust HTTP/2 support, such as Kubernetes clusters, AWS ECS/EKS, or Google Cloud Platform's offerings. For browser clients, remember you might need a gRPC-Web proxy to handle the translation, adding a layer to your deployment architecture.

Community and Ecosystem: The Support Network Behind Each Style

When you're making a significant architectural decision, it's not just about the technical specs; it's also about the human factor. How vibrant is the community? How extensive are the learning resources? How mature is the tooling? These questions are incredibly important for long-term project success and team productivity. My journey has shown me that a robust ecosystem can make all the difference, providing the support you need when you inevitably hit a challenge. Let's explore the community landscape for each API style.

REST: The Ubiquitous Veteran

For anyone starting in web development, REST is almost certainly the first API style you encounter. Its deep roots mean it has an unparalleled support system.

  • Maturity & Pervasiveness: REST has been the reigning champion since the early 2000s, making it incredibly mature and deeply embedded in almost every web framework. Think out-of-the-box support in Express (Node.js), Django/Flask (Python), Spring Boot (Java), Rails (Ruby), Laravel (PHP), and countless others. It's truly everywhere.
  • Learning Resources: The sheer volume of tutorials, blog posts, books, courses, and Stack Overflow answers related to REST is immense. If you have a question, chances are someone has already asked and answered it. It's also integrated into most API documentation tools like Swagger/OpenAPI, making discovery straightforward.
  • Community Size: Enormous and incredibly diverse. REST is often the default developers learn first, creating a massive pool of talent and a strong presence in both large enterprises and agile indie projects.
  • Verdict: Excellent community, extensive tooling, and a highly stable job market. You're rarely alone when working with REST.

GraphQL: The Rising Star with a Dedicated Following

Since its open-sourcing by Facebook in 2015, GraphQL has rapidly carved out its niche, particularly with frontend-focused teams who quickly embraced its client-centric approach.

  • Maturity & Adoption: While younger than REST, GraphQL has matured rapidly and gained significant traction. It's not just a trend; it's widely adopted by tech giants like GitHub, Shopify, and Netflix for critical parts of their infrastructure.
  • Ecosystem & Resources: GraphQL boasts a rich and rapidly evolving ecosystem. Projects like Apollo (with its client and server libraries), Relay, and GraphQL Yoga lead the way. Developers also benefit from fantastic tooling like GraphiQL and GraphQL Playground, which leverage its introspection features to provide an interactive API exploration experience.
  • Community: Strong, vibrant, and growing, especially among frontend developers working with modern frameworks like React, Vue, and for mobile applications. You'll find a wealth of libraries and support in languages like JavaScript/TypeScript, Python, Go, and Ruby. While its penetration might be slightly less in traditional, purely backend-focused environments compared to REST, its momentum is undeniable.
  • Verdict: A modern, active community with great momentum, innovative tooling, and a growing presence in the job market.

gRPC: The Cloud-Native Workhorse

gRPC, also released by Google in 2015, has a different, more specialized trajectory. It's the silent workhorse behind many high-performance, cloud-native systems.

  • Maturity & Adoption: gRPC has achieved significant adoption within infrastructure-level and microservice-heavy environments. It's a cornerstone in projects built on technologies like Kubernetes, Istio, and Envoy, indicating its reliability for demanding internal systems.
  • Ecosystem & Resources: Google provides robust, official support across a wide array of languages, including Go, Java, C++, Rust, Python, and Node.js. The documentation for these official libraries is generally solid. However, you'll find fewer high-level "how-to" tutorials aimed at traditional web developers, as its focus is often on backend-to-backend communication. Integrations with frontend tooling are also less common (often requiring gRPC-Web as a bridge).
  • Community: While smaller and more niche than REST or GraphQL, the gRPC community is incredibly strong and dedicated within specific domains, particularly among infrastructure, DevOps, and cloud-native circles. It's less common for public-facing web APIs but a staple in enterprise SaaS and highly performant internal systems.
  • Verdict: Highly respected and established in the backend/cloud-native world, but remains a niche player compared to REST and GraphQL in the broader web development landscape.

TL;DR Comparison Table: Community & Ecosystem at a Glance

Category REST GraphQL gRPC
Community Size ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐
Learning Resources ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐
Ecosystem Tooling ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐
Popular Industries All (General Web) Web/Mobile (Frontend-heavy) Cloud-native/Microservices/IoT
Beginner Friendly ✅ (Very) Medium ❌ (Steep Learning Curve)

Tooling, Languages & Frameworks: Bringing Your API to Life

One of the most important considerations when choosing an API style is how well it integrates with your existing tech stack and the tools your team is comfortable with. My experience has taught me that the robustness of an ecosystem can heavily influence development speed and long-term maintainability. Here's a snapshot of some common technologies and their support across REST, GraphQL, and gRPC.

Tech REST (Common Frameworks/Libraries) GraphQL (Common Servers/Libraries) gRPC (Common Libraries)
Node.js Express, Fastify, Koa, NestJS Apollo Server, Yoga, GraphQL.js, Nexus @grpc/grpc-js (official Node.js)
Python Flask, Django REST Framework, FastAPI, Falcon Graphene, Ariadne, strawberry grpcio, protobuf
Go net/http, Gin, Echo, Fiber gqlgen, graphql-go, graphql-server google.golang.org/grpc (official)
Java Spring Boot (Spring Web), JAX-RS (Jersey) graphql-java, Spring for GraphQL grpc-java (official)
Rust Actix Web, Rocket, Axum async-graphql, juniper tonic, grpc-rs
C# (.NET) ASP.NET Core Web API Hot Chocolate, GraphQL.NET Grpc.Core, Grpc.Net.Client
PHP Laravel, Symfony (API Platform) webonyx/graphql-php, Lighthouse grpc/grpc (PECL extension)
Ruby Rails (Rails API Mode), Sinatra graphql-ruby grpc

Final Thoughts: Beyond the Hype, Towards Pragmatism

If there's one overarching lesson I've taken from my deep dive into REST, GraphQL, and gRPC, it's this: choosing the right API style isn’t about which is newest, flashiest, or currently trending on social media. It's profoundly about understanding what your project truly needs, the specific problems you're trying to solve, and the existing expertise and comfort level of your team.

  • REST is your reliable, battle-tested workhorse. It's stable, incredibly easy to get started with, and perfect for a vast majority of common web scenarios where simplicity and broad compatibility are key. Don't underestimate its enduring power.
  • GraphQL is your modern power tool for client-driven development. It genuinely empowers frontend teams, streamlines data fetching, and simplifies data management in complex user interfaces. It's a fundamental shift that, once mastered, can significantly boost developer efficiency.
  • gRPC is your high-performance engine for internal systems. It's the precision instrument for microservices, real-time communication, and any use case where raw speed, efficiency, and strong contracts are non-negotiable.

My journey through these architectures has repeatedly shown me that you don't have to pick just one and stick with it forever. In fact, many successful, modern systems are wonderfully pragmatic, adopting a hybrid approach. You might see a public-facing REST API externally, providing broad access; a powerful GraphQL layer for complex frontend clients, giving them tailored data access; and hyper-efficient gRPC internally for blazing-fast service-to-service communication within the backend.

The most valuable advice I can offer, born from personal experience, is to be pragmatic and curious. Explore each option. Learn its strengths and its limitations. Don't let hype dictate your choices. Instead, let your product's unique requirements, your team's capabilities, and your ultimate goals guide your decision.


💬 Which API style do you use the most? Have you tried mixing them in a hybrid system? Share your experiences in the comments below!

📬 If this post helped you unravel the complexities of API design, consider sharing it with your dev circle!

👉 Follow me @matheusjulidori for more practical insights like this every week!

Image of Timescale

Timescale – the developer's data platform for modern apps, built on PostgreSQL

Timescale Cloud is PostgreSQL optimized for speed, scale, and performance. Over 3 million IoT, AI, crypto, and dev tool apps are powered by Timescale. Try it free today! No credit card required.

Try free

Top comments (1)

Collapse
 
vidakhoshpey22 profile image
Vida Khoshpey

I found it interesting so I'll share it wow 💪🏻💻 keep going

Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more

Dev Diairies image

User Feedback & The Pivot That Saved The Project

🔥 Check out Episode 3 of Dev Diairies, following a successful Hackathon project turned startup.

Watch full video 🎥

👋 Kindness is contagious

Explore this insightful write-up, celebrated by our thriving DEV Community. Developers everywhere are invited to contribute and elevate our shared expertise.

A simple "thank you" can brighten someone’s day—leave your appreciation in the comments!

On DEV, knowledge-sharing fuels our progress and strengthens our community ties. Found this useful? A quick thank you to the author makes all the difference.

Okay