tRPC vs GraphQL API Frameworks

Manuel Aparicio

Aug 29, 2023

tRPC and GraphQL are the two modern frameworks for building API in Software Development. They both introduced innovative ways to improve how developers work with APIs and handle data fetching. GraphQL was the first alternative to REST APIs' under and over-fetching issues, making its popularity grow in the blink of an eye. That's one of the many reasons it became the API's heavyweight champion of large JavaScript projects. As a matter of fact, its usage skyrocketed from 6% to up to 40% in only a few years, with 94% satisfaction among developers.

However, tRPC has come out of nowhere to challenge GraphQL's title. Although it came out only a few years ago, many developers have fallen in love, and there are many reasons for that. tRPC is probably the simplest and most lightweight framework for API development. That's why we're comparing it to the giant GraphQL. In essence, it's probably fair to say that tRPC and GraphQL can accomplish the same goals. Yet, there's a world of difference in how they work and the developer experience they provide. That said, there are quite a few things to consider to decide which is right for you.

What is GraphQL?

GraphQL is a Query language for API development that allows to read and mutate data in APIs. It has a robust type system lets backend developers define a clear API schema. This way, frontend developers or any user of the API can explore and request the exact data they need. That's how it solves the REST's under and over-fetching issues. I bet you've heard this popular analogy about traditional REST APIs that says they are like servers in a restaurant.

They take orders from the customers (API consumers) and go to the kitchen (the server) to get them what they requested. You can imagine GraphQL as a means for a server to get customers everything they request in one go, regardless of the order's size. Plus, customers can decide what the server will get them way more efficiently. Backend developers define entry points on the server side in the GraphQL schema as root Query and Mutation types. They use the keywords query and mutation, respectively. Let's look at a few examples.

1. GraphQL Queries

Queries define the structure and requirements of the data the users request from the server. They are similar to the GET method in RESTful APIs. Here's a basic example.

query GetCoffee {
coffee(id: "123") {
  id
  name
   origin {
   country
   region
}
roaster {
   name
   location
  }
}
}

2. GraphQL Mutations

GraphQL API's consumer, on the other hand (the user), uses mutations to initiate a request that modifies the data. Thus, mutations work like POST, PUT, PATCH, and DELETE requests in REST. Let's take a look at another example.

input CoffeeInput {
name: String
origin: String
roaster: String
}
mutation AddCoffee($coffeeInput: CoffeeInput!) {
addCoffee(coffee: $coffeeInput) {
  id
  name
  origin
  roaster
}
}

"coffeeInput": {
"name": "Colombian Supremo",
"origin": "Colombia",
"roaster": "Coffee Roastery Inc."
}
}

What is tRPC?

Unlike GraphQL, tRPC API doesn't involve a whole new language to handle client-to-server communication. Its simplistic approach uses TypeScript functions on the app's client side to make remote calls requesting server data. That explains why its name stands for TypeScript Remote Procedure Call. Like GraphQL, it allows the user to get a quick response containing only the requested data. Yet, it doesn't involve a schema to do that. It's as simple as a protocol that TypeScript functions to expose your backend functionality to the frontend. No wonder why it has become so popular.

The main caveat here is that it requires the project to have TypeScript, both in the Front and Back-End. Yet, that's nothing major when you think about all its benefits. Strong IDE support with auto-completion, automatic type safety, and batching are some of tRPC's main benefits. They all translate in a more intuitive and easy-to-maintain way to handle client-to-server communication.

Let's now take a look at an oversimplified example of how tRPC may look in your project. Believe it or not, it's that simple.

import { createClient } from '@trpc/client';
import type { CoffeeRouter } from '../server/routers/coffee';
const coffee = createClient <CoffeeRouter>({
url: '/api/coffee',
});
export default coffee;

Here, the createClient function takes an object that defines the router that the user should use to access the backend. We're using the CoffeeRouter that we defined on the server. Once we've created the user, we can use it to make requests to the server like this:

import coffee from '../lib/coffee';
async function getCoffee() {
const beans = await coffee.query('getBeans');
return beans;

The query method takes the method's name we want to call on the server and returns a Promise that resolves with the result of the method call.

GraphQL vs tRPCFrameworks

tRPC vs GraphQL: Popularity

GraphQL came out in 2015 and has gained many developers' love ever since. Currently, it's the second most common option to handle client-to-server communication, only behind REST. For those reasons, GraphQL clearly surpasses tRPC regarding popularity and adoption. As a result, it may be simpler to assemble a team with hands-on experience on GraphQL. However, it's not a secret that TypeScript is one of the most popular and loved languages. TypeScript developers should be able to pick tRPC quickly, even if they don't have previous experience with it.

tRPC vs. GraphQL: Flexibility

GraphQL supports a wide range of technologies and programming languages. That includes React, Node.js, Python, Java, Go, Clojure, Scala, and .NET. Therefore, it's fair to say that GraphQL is very flexible. However, GraphQL is a query language, meaning you'll have to learn a new language if you don't have previous experience with it. On the other hand, tRPC requires both frontend and backend developers to use TypeScript. That's a constraint for developers who prefer other programming languages.

tRPC vs. GraphQL: Ease

To be blunt, tRPC has given us the easiest way to connect and handle client-to-server communication. Instead of using a new language as you implement a schema to connect the front and the backend, tRPC just focuses on TypeScript functions. The comparison here probably isn't even fair since tRPC is a library developers can implement out of the box. So long as they know TypeScript, of course.

Developers who choose GraphQL will have to build an API with a schema. tRPC also allows for end-to-end type safety, making it a straightforward tool. Another thing to consider is that GraphQL will enable you to query multiple data sources more easily. It'll simplify things by providing a single codebase (a monorepo).

tRPC vs. GraphQL: Performance

GraphQL and tRPC are excellent options for apps that handle massive amounts of data messages requiring minimal delay. Both allow users to get a quick response that contains only the data they need, reducing network overhead and improving performance. As a result, there isn't a significant difference in their performance if the project is small or medium-sized. However, GraphQL excels at efficiency when fetching deeply nested and complex data.

Conclusion

When working on small or medium projects that don't require overly complex architecture, GraphQL and tRPC are two powerful tools that can accomplish the same thing. Seamless, efficient technology for client-to-server communication without network overhead. Regarding its ease of use, it would probably be best to use tRPC if you're working on a project with TypeScript both in the front and backend. If it's a small or medium-sized TypeScript project and only a few developers work on it, it's a no-brainer. If your project involves multiple codebases and complex architecture, GraphQL might be the best API method for you. Know that you know this, you can choose the one that offerts the key features for you. Happy coding!

Our human-centered approach and hard-earned reputation make us able to deliver successful, top-notch, and stunning products. Whether you're looking to move from an idea into a business or thinking of new iterations for your product, our UX-focused Custom Software Development company is here to help. Feel free to reach out, and let's shape the future together!