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.
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.
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.