While we normally use GraphQL to get data from the server to the client, tRPC provides a simpler, more streamlined experience for our developers, helping us make better apps for clients.

Dennis Chiroro

Erlang

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

GraphQL has been the API layer for dozens of apps developed by Echobind. Both GraphQL and tRPC are perfectly compatible with React and React Native and have first-party client-side library support. Both support end-to-end type checking, with GraphQL requiring a codegen step.

Why we ditched GraphQL for tRPC

I’m sure there’s a bright future for technologies like tRPC. But it seems like most of the problems described are not because of GraphQL, but the tools being used for GraphQL:
<ul>
<li>The combination of Prisma and Nexus, which gives you the double declaration, is a choice of the author. There are different tools out there that save you this hassle</li>
<li>Apollo Client can be substituted for React Query when using a GraphQL API as well</li>
</ul>

tRPC + React Query + Prisma gives full end to end type safety from the database to the frontend. Stacks like T3-Stack implement it already. How great is that ;)

trpc is great! I’ve noticed as I scale projects typescript gets a little slow. A fair price to pay for type safety though!