tRPC: the TypeScript API
If you're a full-stack developer, you know the pain of developing APIs with REST or GraphQL. REST APIs are great for simple requests but can quickly become complex and hard to maintain. GraphQL APIs, on the other hand, have a steep learning curve. But what if I told you there's a better way? In this article, I'll introduce you to tRPC, which revolutionises full-stack TypeScript development.
Hey, everyone! I'm David, I’ve been developing for… well, since the last millennium. And I was intrigued when I first heard about tRPC. You see, when Node.js first came out, I was excited about being able to share code and types across client and server projects.
In practice, things weren’t that simple. This is where tRPC comes in. At its core, tRPC is a way of sharing type information between the client and the server.
So… what is tRPC? What does tRPC even stand for?
What is tRPC?
Let’s split that in two. RPC means Remote Procedure Call, which is an old-school way of doing client/server interaction that predates even REST. tRPC is an open-source framework inspired by how RPC used to work.
The second part of the name is tRPC’s main strength but also its greatest weakness. You see, the “t” in tRPC refers to Typescript. tRPC is great when you’re working on a full-stack application where both sides use TypeScript.
If you need to create a public-facing API or if your stack has other languages, tRPC is out of contention. But to me, if you’re using Typescript on the server, on the web, and to develop a native application… nothing beats tRPC. Allow me to explain why.
tRPC vs REST
Let's start by comparing it with REST. REST is great for simple requests but quickly becomes complex as your API grows. You end up with many endpoints and nested routes, which can be hard to maintain. And REST is a recommendation, not a standard. There are many ways of being RESTful, and this means you also need strong versioning and documentation.
With tRPC, you don’t worry about endpoints and how to talk to them. Instead, you define the server methods you want your client to be able to call, and the framework does the rest of the work. It’s the code itself, the TypeScript, which _is _ the documentation. This results in a clean and organised codebase that's easy to maintain.
tRPC vs GraphQL
Now, let's compare tRPC with GraphQL. GraphQL has a steep learning curve. It’s a new language to learn. After all, QL stands for Query Language. Now, GraphQL is self-documenting. The schema is a contract stating: this is the data I deliver. This is the data I’m expecting to be queried with. It solves many of REST’s drawbacks.
But TypeScript is already all about defining our data’s shape. With tRPC, you define your data structures using TypeScript interfaces, and the framework ensures that type information is shared between the client and server.
We help you better understand software development. Receive the latest blog posts, videos, insights and news from the frontlines of web development
tRPC’s strengths
Now, what are tRPC’s strengths? First, it's easy to learn and use, even for developers who are new to API development. The framework generates the boilerplate code for you, so you can focus on writing business logic. Second, tRPC is type-safe. This means you can catch errors at compile time instead of runtime. Third, tRPC is fast and efficient because it batches server calls together.
tRPC’s limitations
Of course, tRPC isn't perfect. It has some limitations compared to REST and GraphQL. For starters, as I mentioned before, it is only suitable for fully TypeScript projects. To make the most of it, you should structure your clients and server code as a mono-repository, for example, using TurboRepo. tRPC is less suitable for outside consumption, which is one of the main purposes of APIs.
Despite all this, tRPC is a game-changer for API development when the conditions are met. It offers a unique approach that combines the best of both REST and GraphQL while addressing their limitations. It's easy to learn and use, type-safe, and fast and efficient. If you're looking for a better way to build APIs, give tRPC a try. It produces a closer cooling between the frontend and backend code. In the right circumstances, it can make your life so much easier.
tRPC in practice
Now, I’ve had several comments in the past about you guys wanting to see more of all this in practice. So over the coming weeks, I’ll be creating a full-stack application using TypeScript, Next.js, Prisma, tRPC, TurboRepo, React Native and Auth.js.
We’ll start with the initial setup and build up from there, and as soon as it is up, you can click here to follow along. If you want to get started on your own, there is a starter solution called “create-t3-turbo” which brings all those bits together.
And in the meanwhile, if you have any questions or suggestions, please leave them in the comments below; I’ll be glad to help.