In this blog, we will take a look at tRPC vs GraphQL and try to form an understanding of why they exist, what problems they solve and which one is best for your next project.
What is tRPC?
tRPC is a framework for building data fetching and API layers in Next.js, React and React Native applications.
It is flexible and easy to use – while still providing a great developer experience.
tRPC is open source and free to use.
When creating an API with tRPC your data along with typescript, types are being sent to the client providing them autocomplete directly from the IDE avoiding any need for external API docs
It essentially allows you to define functions in your server and call them remotely. similar to RPC ( remote procedure call).
What is GraphQL?
GraphQL is a query language used for APIs and a runtime for fulfilling those queries with your existing data. It provides a complete and clear description of the data in your API, gives clients the authority to ask for exactly what they require, makes it easier to evolve APIs over time, and enables strong developer tools.
tRPC vs GraphQL
tRPC is not a schema. it is a protocol in which you can call your backend typescript functions from your front end.
While graphQL is a schema and a language that describes your backend, everything it can do, and the shape of that data in a graph.
Why choose GraphQL over tRPC?
GraphQL acts as a contract agreed upon by the frontend and backend teams to promote the separation of concerns.
It offers a lot more features and is extremely useful when building internal APIs.
tRPC uses typescript on both the frontend and backend. therefore you cannot use trpc with other languages
Why Choose tRPC over GraphQL?
For most use cases graphQL seems to me a bit overkill, considering that a lot of companies use graphQL because other much bigger companies use graphQL without understanding that they might not need to use graphQL right now.
GraphQL is expensive because the skill required to build effective graphQL APIs is extremely valuable and newer companies that can’t afford or need the features graphQL offers tend to buy into it and spend a lot of time understanding and developing GraphQL APIs
I like to think that GraphQL is like API REST with extra steps to make it more complex but stricter and more powerful because of good reason and tRPC is taking a step back from rest to RPC and making it type safe cutting out a lot of the complexity
The Future of tRPC and GraphQL
GraphQL is currently a major entity in the API space right now but I do believe as more companies of a smaller scale take the time to evaluate whether or not they require this complexity, tRPC would get more traction.
Conclusion
A good argument is possible as to how we would consider a company to be big or small if we were to take userbase or the amount of complexity it has to deal with or some other factor.
I’ve spent some time thinking about this and I believe a company becomes big by the amount of money and time people are ready to invest in it.
If time and monetary investment are not an issue and there exists a specific good reason graphQL is probably the best way to go forward.
However, if your API is possible much more simply and does not necessarily need to be complex, I think tRPC is the way to go.
