Comparing REST, GraphQL & tRPC

#rest #graphql #trpc #openapi

As an author and maintainer of open source libraries to work with REST APIs, and as someone making a living building an API First SaaS product with both REST and GraphQL APIs, I sometimes encounter strange attitudes towards different API styles.

"REST is outdated" "GraphQL is only good for mobile dev" "tRPC is too new for production" "No one likes to work with swagger"

It might be tempting to pit these technologies against each other, but the reality is, these paradigms are not direct competitors. Instead, each has its own unique strengths and use-cases, crafted for specific contexts and developer needs.

I was reminded of this fact recently when writing comparisons between my own open source REST tooling vs. GraphQL and tRPC:

Let's take a deeper look at each technology and its strengths:

GraphQL

GraphQL is a query language for APIs developed by Facebook. It gives API clients full control over the data they query, making it extremely flexible and efficient for client-centric use cases.

GraphQL APIs define a strongly typed schema for the data and mutations they support which makes them discoverable and intuitive to develop against.

Teams building with GraphQL naturally take the API First (or Schema First) approach where the API contract is treated as a first class citizen in the software design instead of treating it as merely documentation.

When developing an app with a GraphQL API, it's common to use the GraphQL schema as the single source of truth for data models used within the application, and source types from it used end to end across the codebase.

GraphQL APIs are often used as gateways, merging multiple downstream APIs into a single, easy to use interface for a great application development experience. I would consider this one of GraphQL's killer apps.

Facebook's excellent Apollo GraphQL is definitely a best-in-class example of great API development experience.

REST

REST has been around for a while now. It's still probably the most widely adopted HTTP API design paradigm perhaps due to its resource-based implementation simplicity and the ability to leverage standard HTTP features directly.

With widely adopted open standards to define REST APIs, like OpenAPI specification (previously known as Swagger), REST can be used much like GraphQL with a single source of truth for the API contract.

Full disclosure: my own open source work in the last few years has revolved around the mission of bringing a GraphQL-like developer experience and type safety with OpenAPI for REST.

While REST APIs don't generally provide the same level of control to clients as GraphQL, sometimes this could be seen as a benefit especially in scenarios where strict control over data access and operations is crucial.

Widespread knowledge around REST contribute to its choice among organizations looking for a tried-and-tested approach to building APIs.

tRPC

While RPCs are by no means a new idea, tRPC is seen as the new kid on the API block. Much loved by developers who just want to build fast and do it with type safety.

Designed for full-stack Typescript applications, tRPC allows direct sharing of types between both the client and server, without relying on code generation.

Unlike GraphQL and REST, tRPC doesn't expose a standard machine-readable API schema to be consumed by clients, instead taking a more straightforward approach of exposing endpoints or procedures, essentially "just functions" invoked by the client to the server.

While the lightweight tRPC approach is optimal for teams just looking to build full stack applications, teams looking to build robust, re-usable APIs may better be served by the API design first approach of GraphQL or OpenAPI.

(I wonder if tRPC will eventually get its own YAML specification language)

Conclusion

In the landscape of software dev, it's easy to get caught up in the rhetoric of one technology being superior to another. But as we dive deeper into the nuances of GraphQL, REST, and tRPC, it becomes evident that each serves its unique purpose and has been created to solve specific problems in API development.

The right choice of an API paradigm is definitely not a one-size-fits-all solution.

It's essential to remember that the success of an API doesn't necessarily depend on the technology backing it, but more on its clarity, usability, reliability, and the developer experience it offers.

Technologies change, but the principles of good API design and the goal to write delightful, working software remains constant.

If you're interested in my Open Source work around API tooling, check out openapistack.co