[haney]

I'm currently in the process of removing tRPC from our codebase. It's been a nightmare of tight coupling. I've also found that it encourages more junior developers to not think about interfaces / data access patterns (there's a mapping from Prisma straight through to the component). It's fantastic for rapid prototyping but really paints you into a corner if you ever want to decouple the codebase.

[miraantabrez]

This is the overlooked advantage of a schema (e.g. in GraphQL): it forces you to think about the data types and contract, and serves as a good way to align people working on different parts of the code. It also scales to other languages besides TypeScript which helps if you ever want to migrate your backend to something else or have clients in other languages (e.g. native mobile apps in Swift, Kotlin, etc).

[spankalee]

TypeScript is actually a great schema language and fixes a number of problems in GraphQL's SDL, especially the lack of generics.

I think if you're defining a JSON API, that TypeScript is a natural fit since its types line up with with JSON - ie, number is the same in both and if you want something special like an integer with more precision, then you have to model it the same way in your JSON as your TypeScript interfaces (ie, a string or array). This makes TS good even for backends and frontends in other languages. You can also convert TS interfaces to JSON Schema for more interoperability.

[thinkingkong]

We implemented tRPC at work and use all the other things that would have been 'tightly coupled' within our code base had we not planned a tiny bit ahead. tRPC is incredible but it's still just the transport layer between your back-end and your front-end. Allowing the internals of tRPC to be used deep within your business logic is just as bad as not having a clear 'controller' or 'router' layer where you can cleanly define inputs, schemas, and keep things separated. In this sense, if we ever decided to move from tRPC it would be relatively straightforward. Lifting an entire sub-system and running it over a queue for example would be trivial.

[Swizec]

Your problem isn’t tRPC, your problem is that you have engineers who type things for typing’s sake. They’ll have the same problem in any tool.

There’s a learning curve to these things. It always starts with type FunctionIWroteTodayArgs = …, which is useless and tells you nothing.

After a few iterations (this takes years) people gradually realize that the goal is to describe your domain and create types/interfaces/apis that are reusable and informative, not just a duplication of your code. You then get more useful types and things start really flying.

I guess what I’m saying is work on that with your team, not on ripping out tRPC.

[killthebuddha]

+1. Almost every time I actually write out a type it's because I want to communicate some domain knowledge. For everything else I use inferred types. IMO this is The Way.

[dclowd9901]

Eh? Useless? Maybe you’ve not written generic Javascript before but “type FunctionIWroteTodayArgs” has eliminated an entire class of problems we used to face with JS code.

If you’re talking about decoupled services, that’s about business domain composition more than type description. And those types benefit from a higher level description/reusability/transportability.

[epolanski]

Could you expand on the nightmare of coupling?

I don't see how declaring an http client server side and consuming it client-side can be a worse thing.

We use the same pattern of creating services that then every consumer can use (a web interface, a cli, etc) and the fact that those things never get to break is a massive improvement over anything I've seen in the past.

[haney]

If you only ever use Typescript and are sure you’ll never need to interact with the code in any other language or service in a different repo it’s fine. But as soon as you need to reuse that backend for anything else you’re stuck building something new.

[welder]

Having the opposite experience with it as a small team, and I can see how it would work great in my past large teams. I bet you're gonna have the same complaints about any API you use not just tRPC (junior developers not thinking about interfaces).

[haney]

I’m willing to admit that poor usage can make any tool a problem. But, tRPC is set up to make it easy to directly expose your backend for use in a component. For new projects that’s fantastic, for larger projects and teams having the ‘friction’ of defining a gRPC, GraphQL or REST endpoint is leading to more thoughtful API design and ability to keep isolation between layers.

[macrael]

It's a dangerous anti-pattern to pass your db types through to your api handlers. Those are always different models and it's important to have an intermediary representation for the rest of your domain.

[calebio]

Agreed. Although, sometimes it feels like this is a losing battle. I've worked with too many people who see that level of separation as "unneeded duplication", with constant complaints about having to update a bunch of different layers "just to add a new field.

IMO, at a minimum, you have your API layer model, your internal model, and your database model with a mapping layer at each boundary.

I rarely have problems when I structure it that way, but when working on applications that pass the same model from their API down to their database, or vice-versa, it's always full of the same types of problems that comes with tight coupling.

[yieldcrv]

our problem with tRPC is that we don't have an easy to way to test the endpoint in say, curl or postman.

there is a “REST Wrapper” project out there, but learning that was even needed was … fun

I don't mind it, we found other ways to test

Out of curiosity, how do you add a memcache to tRPC if you dont want to write directly to the prisma database

[JCharante]

I use trpc playground. It takes a few lines to setup.

[vendiddy]

There are libs like ts-rest which I found to be less magical and easier to test.

[alexdotjs]

We a tool bring which lets you track schema changes it over time and also ability to have an approval workflow for schema changes.

Would that help your team?

Happy to give you a demo if you reach out on Twitter dms or email ([e-mail])

[replygirl]

is it git?

[random_kris]

Care to elaborate further? I've been building on top of trpc and even for inter service communication we use it