Fullstack TypeScript: From GraphQL to TRPC

---

Introduction

Speed and quality in code delivery can make or break a project. We experienced a significant boost when we transitioned from GraphQL to TRPC in our Fullstack TypeScript framework. Let's dig in.

---

Our GraphQL Journey in Fullstack TypeScript

We started our journey with GraphQL because it seemed like the perfect match for our Fullstack TypeScript setup. GraphQL offered a strong contract and type safety between the frontend and the backend. It is a great tool, but our team encountered some friction around the tooling and boilerplate.

---

Why We Explored Alternatives

As we scaled our project, we noticed the developer experience was less than ideal. Each time we added or updated a query, it involved multiple steps: modifying the schema, updating the frontend queries, running code generation tools, and ensuring type safety. It started to feel cumbersome.

---

Our Modern Stack Overview

Our tech stack remained consistent regardless of whether we used GraphQL or TRPC. It consisted of:

• Frontend: React
• Backend: Express
• Repository: Monorepo

---

The Tools That Powered Us

For both setups, we relied on the following tools:

• Nx for monorepo management
• NodeJS and Express for the backend
• React SPA for the frontend

---

The Challenges We Encountered with GraphQL

While GraphQL served us well initially, a few roadblocks started to appear, especially concerning the developer experience. One key issue was the extra steps needed to manage queries and mutations. We had to:

1. Many steps to manage queries and mutations:
   • Update the backend schema
   • Tweak the frontend query
   • Use codegen tools
   • Check that types updated in the IDE
2. Difficult Learning Curve:
   • The steps needed for queries and mutations added complexity, making it tough for newer devs to catch on quickly.
3. Hard to Navigate:
   • Jumping from client-side code to the corresponding backend code was a challenge.

With these challenges in mind, we looked for alternatives to streamline our development process.

---

How TRPC Changed the Game for Us

That's when we found TRPC. This TypeScript-based remote procedure call tool simplified our life. In our new workflow, we just:

1. Write a query or mutation in a TRPC router on the backend
2. Call the query on the frontend using the TRPC client

TRPC removed the need for manually generating types and running codegen tools. Our development speed increased, and the number of steps to add or update a query significantly reduced.

---

Real Benefits We Noticed

Switching to TRPC didn't just make coding simpler; it came with real perks:

• Faster Development: Fewer steps help us code quicker.
• Reduced Errors: The TRPC client sorts out types, so less chance of type mistakes.
• Enhanced Developer Experience: No need to update types by hand or redo code. This saves us time and energy.
• Seamless Validation with Zod: TRPC and Zod work well together, making it easy to check data and build stronger apps.
• Real-Time Autocompletion: TRPC gives instant code hints, speeding up how fast we write code.
• Jump to Code: Easy navigation from client to backend code, so we find what we need fast.

This shift to TRPC really made a difference in how we work and what we can do.

---

Conclusion

Switching to TRPC in our Fullstack TypeScript setup was a big win for us. If you're facing the same bumps with GraphQL, making the move could help you as much as it did us.

Don't get us wrong, GraphQL is still an excellent choice, especially if you're building public-facing APIs or if your backend is written in another language. But for our team's needs, TRPC hit the mark.

We hope our story gives you an idea of what TRPC can do in a Fullstack TypeScript world. Give it a try; it might be the change you've been looking for.

If you want to learn more about our experience or need help with a similar project, feel free to get in touch. We're here to help!