API typesafety without the tears (or code generation)

I want to acknowledge the great work that has gone into this tool, which seems to be practical and elegant. This blog post, though, has some needlessly provocative statements that distract the reader from the utility of tRPC.

The image of GraphQL's epitaph implies that tRPC is killing or will GraphQL. This is misleading: as you acknowledge in the text of the article, GraphQL is a specification that is language-agnostic. tRPC is not language-agnostic, nor is it a spec, so why use such stark imagery?

I also need to point out this snippet:

> But the vast majority of projects that use GraphQL are JavaScript-based. The graphql NPM module has 5M downloads/week vs ~300k) for the graphene Python module and ~230k for the graphql Rubygem. It's not a perfect metric, but the signal is clear.

I disagree that there's any clarity or signal to be had from these figures. Node, Python, and Ruby package management paradigms are all different. "It's not a perfect metric" is an understatement, and "the signal is clear" is an overstatement.

> As TypeScript approaches near-universal adoption in the JS ecosystem, that means most GraphQL-based projects will soon be TypeScript-based (if they aren't already).

Again, this is overstated. "Near-universal?" How could you possibly substantiate such an outlandish claim? I suggest you scale down the claim to "as TypeScript continues its rise in the JS ecosystem,".

But perhaps the most relevant hand-wavery in the entire article is as follows:

> Here's the thing: most people use GraphQL as a massively over-engineered way to share the type signature of their API with your client.

A citation is sorely needed here. My team is using GraphQL in a production app serving millions of users - its type system is great but only one of many features we're interested in.

Again, tRPC looks fantastic - it sells itself without the puffery and half-truths you've used in an otherwise excellent article.

Author here. Most build tools for end-to-end typesafe APIs rely on code generation, notably OpenAPI and GraphQL. Codegen works, but it inevitably introduces lag and friction into the developer workflow. The fact that modern TypeScript makes it easy and safe to share type signatures between any two TypeScript projects is majorly underdiscussed and underutilized. I think some sort of "TypeScript-native" typesafe API library[0] is inevitable as a growing fraction of web projects are fullstack TypeScript. Excited to see how this all pans out!

[0] https://trpc.io/

Isn't not being bound to TypeScript a feature, not a bug?

Code generation definitely sucks, but it seems like a real solution would be to (somehow) get schema files importable into the language instead of imposing the language outwards. In js land this isn't even unprecedented.