GraphQL vs tRPC: Which one is better for your project?
Tags: webdev, javascript, typescript, programming
Published: 2022-12-03 10:31:45

Are you tired of using clunky, outdated APIs for your projects? Are you ready to take your development to the next level with modern, efficient technologies? If haven't already, you need to check out tRPC and GrapQL!

<sup><center><small><small><i>Note: tRPC is intended for full-stack TypeScripters</i></small></small></center></sup>

They're quickly rising in popularity and I am seeing them mentioned frequently. But one thing I notice is a lot of people aren't really sure what sets them apart!


![Harold](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6x8vz7ymd1tyq88ixf1c.png)
<h1>
<br>
<center>GraphQL and tRPC are both technologies for building APIs, but they have some <strong>key</strong> differences.</center><br></h1>

One of the main differences is that GraphQL is a query language for APIs, whereas tRPC is a fully typesafe (the t stands for TypeScript) remote procedure call (RPC) framework. This means that with GraphQL, clients can specify exactly the data they need from the API, and the server will return only that data, whereas with tRPC, the server provides a pre-defined set of procedures that the client can call to perform certain actions or retrieve data.

<center><h1>GraphQL uses a schema</h1></center><br>

Another key difference is that GraphQL is based on a [schema](https://www.ibm.com/cloud/learn/database-schema), which defines the types of data that can be queried and the relationships between them. This allows for strong typing and self-documentation of the API, which can help with development and debugging. tRPC, on the other hand, does not have a schema and relies on convention and pre-agreed upon data formats for communication between the client and server.

```js
type Query {
  posts: [Post]
  users: [User]
  comments: [Comment]
}

type Post {
  id: ID!
  title: String!
  content: String!
  author: User
  comments: [Comment]
  likes: Int
}
```
<small><small><center>Strongly typed example of a GraphQL schema</center></small></small>


GraphQL really draws a hard line between your frontend and backend. It is especially useful with larger development teams, or teams that can't communicate well because the data that is being exchanged is essentially pre-defined to fit together- but the implementation is left to the developer.

On the other hand with tRPC, you can think of it like exposing functions already defined in the backend to the frontend or vice-versa. This can make it easier to understand and use the API, especially for developers who are familiar with the concepts of RPC.

```ts
import { createReactQueryHooks } from '@trpc/react';
import type { AppRouter } from '../pages/api/trpc/[trpc]';
export const trpc = createReactQueryHooks<AppRouter>();
```
<small><small><center>Example hook defined using API's type signature that can be called from the client, typically using a higher order component</center></small></small>

<br>

In contrast, GraphQL requires clients to construct their own queries to retrieve data, which can be more complex and require a deeper understanding of the schema and data relationships.

Another difference is that GraphQL can be used with any transport layer, such as HTTP or [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API), while tRPC is built on top of HTTP/2 and uses gRPC as the transport layer. This means that tRPC requires HTTP/2 support on both the client and the server, whereas GraphQL can be used with any HTTP client.

<center><h1>Conclusion</h1></center>

Overall, the main differences between GraphQL and tRPC are their approach to defining and accessing data, their reliance on a schema and strong typing, and the transport layers they use. 

Both technologies have their own advantages and use cases, and as always-- which one is right for your project will depend on your specific requirements.


![Always find a balance](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kpcz2t0s31sxnovlelqw.png)

<b1>

Thanks so much for reading! Transfer of data is the name of the game, so I always like to learn about new technologies. If you enjoyed this blog post consider giving me a like so other people can find this resource :) HAPPY CODING!!!!!