For a new Fullstack TypeScript project, I'm torn between the traditional GraphQL/Apollo setup and the newer TRPC approach with Next.js App Router. GraphQL feels like overkill for a single-client app, but I worry about scalability. What are you seeing in the industry for mid-sized enterprise apps this year?
3 answers
If you are building a "Mono-repo" where the frontend and backend share the same TypeScript codebase, TRPC is a dream for developer experience. The "type safety" without code generation is incredibly productive. However, the moment you need to expose your API to third-party developers or multiple mobile apps, GraphQL wins hands down. We used TRPC for our internal admin dashboard but stuck with GraphQL for our public-facing marketplace. It’s not about one losing to the other; it’s about choosing the right tool for the consumer of the API.
Does TRPC handle complex relational nesting as easily as a GraphQL fragment, or do you find yourself over-fetching data more often?
We stuck with GraphQL because our data comes from five different microservices. Aggregating those in TRPC would have been a nightmare compared to Apollo Federation.
Exactly, Rebecca. For distributed systems, GraphQL acts as the perfect gateway. TRPC is amazing for "BFF" (Backend for Frontend) patterns but struggles in a fragmented microservices world.
Kevin, TRPC doesn't have the "selection set" logic that GraphQL has, so you do have to be more intentional with your procedures to avoid over-fetching. We solve this by creating specific "View Models" for different UI components. It requires more backend work than a generic GraphQL query, but the trade-off is zero runtime overhead and a much smaller bundle size. For most mid-sized apps, that speed is worth the extra procedure definition.