Explore tRPC as an alternate interface to GraphQL

[javiertoledo]

Feature Request

Description

As a developer, a tRPC based interface could be used to communicate with web-based single page applications written in TypeScript. An API-less solution like tRPC could potentially provide better type safety, performance, development experience, and flexibility than GraphQL for TypeScript projects.

Some possible benefits of using tRPC over GraphQL are:

• Type sharing between client and server without relying on code generation or schemas
• Direct calls to backend functions from the frontend without writing resolvers or queries
• No restrictions on how to structure data or logic

Some possible drawbacks or challenges of using tRPC over GraphQL are:

• It's not easily interoperable with other languages or frameworks that use other languages than TypeScript
• Less standardization and documentation compared to GraphQL, which is a widely adopted specification
• Less support for features like caching, subscriptions, or batching that GraphQL provides

[russell-dot-js]

As someone who looked into adding a tRPC interceptor for NestJS, I just wanted to give you a heads up that tRPC fell short of my hopes and dreams. It is not a very mature or flexible framework, and you lose a lot of the ability to do things your own way (what you listed as a possible benefit "No restrictions on how to structure data or logic" is actually a drawback "Forced to structure your code in the way that tRPC requires").

You also do still need to define queries & mutations with tRPC, but then you lose the ability to select what fields you get back in your response. One of the main motivations for GraphQL was to serve modern applications to devices with poor internet speeds, allowing the client to decide what data it would like to retrieve, and to retrieve it in as few requests as possible.

Not to mention the lack of a standard spec like GraphQL is extremely painful if you are trying to expose a microservice or public API that can be consumed elsewhere. tRPC is only meant to be consumed in typescript, and sure you could examine the network requests and roll our own clients in other languages, but why?

My desire to work on a tRPC interceptor for NestJS was soured when I read this comment and saw that the maintainers of the library didn't seem like the most pleasant people to work with: https://github.com/trpc/trpc/discussions/1504#discussioncomment-3834142

Looking into a standard like GRPC for microservices, or REST + OpenAPI or json schemas if you want to support a public interface other than GraphQL, might be more fruitful than tRPC, but at this point it seems GraphQL is king.

[javiertoledo]

Hey @russell-dot-js, thanks a lot for sharing your experience on this. We'll definitely take that into account. For now, we're sticking with GraphQL, but I'd love to generalize Booster's API generator enough to make it pluggable, and users can inject their preferred API implementation, maybe having GraphQL, REST, GRPC, or other contributed libraries.