[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.

[tshaddox]

It’s not a perfect mapping with JSON. Everyone knows that stuff like functions and dates can’t go over JSON, but there are also subtler things, like the fact that undefined can’t exist as a value in JSON. I’ve seen codebases get pretty mixed up about the semantics of things like properties being optional versus T | undefined.

[nrclark]

> Everyone knows that stuff like functions and dates can’t go over JSON, but there are also subtler things, like the fact that undefined can’t exist as a value in JSON

I use `null` for that purpose, and it's been pretty reliable. What are the situations where that falls down?

[tshaddox]

I also like null | T for required properties, but for whatever reason I have seen that undefined | T is a much more common convention in the TypeScript world. Maybe the reason for that is the semantic about how object access returns undefined, but that’s precisely the source of ambiguity between “object has property X with value undefined” and “object does not have property X”.

[Cannabat]

TS is a pain with JSON Schema or OpenAPI because it doesn't directly support things like integer or precision. TS does not easily support things like `"exclusiveMinimum": 5`, `"type": "integer"` or patterned (regex) fields.

So if you want to convert your TS interfaces to JSON Schema, you may need to provide additional constraints via JSDoc and use a generator that understands those annotations. But your TS interfaces cannot express those constraints directly.

There are a number other related complications surrounding these more expressive schema definitions - like building types from them and interacting with them at runtime.

[pcthrowaway]

You can easily express constraints like these with Zod though (created by the same person who created tRPC v1)

[Cannabat]

Sure, if you have TS in your backend. There are OpenAPI to zod generators that can help get you started, even if they don’t give you perfect zod schemas out the gate.

[throwawaymaths]

Jesus, if you're making a JSON API just use JSONSchema, which while not perfect, is quite nice for language interop (and more powerful than typescript)

[jitl]

> just use JSONSchema

I'll "just" use the type system built into my programming language until the pain of supporting multiple languages is more expensive than installing JSONSchema tooling and messing with code generation.

[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.

[Swizec]

Fair, it’s not literally useless, it does help with typos and autocomplete. But you can get so much more with just 10% extra care in how you design your interfaces that the lazy approach feels almost useless by comparison.

It’s similar to the problems you run into by writing the wrong kind of tests – the ones that essentially just duplicate your code instead of validating input/output at boundaries.

[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.

[vosper]

You can make calls to tRPC endpoints from anything that can send an HTTP request. The RPC format for requests might not be your cup of tea, but it works.

[Supermancho]

Ostensibly, the product isn't as useful as the existing gotos (json schemas, shared libraries, graphql, etc), if you cannot create a shareable schema for validation. The ability to form arbitrary requests is already assumed. If your messages are very complex, you need some tooling.

[vosper]

If you’re in TS world then you can export the Zod schema that your tRPC queries/mutations are using.

[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.

[welder]

> having the ‘friction’ of defining a gRPC, GraphQL or REST endpoint is leading to more thoughtful API design

Make devs slower so they code smarter?

More friction is just that, it just frustrates devs it doesn't make them code better.

tRPC enables good teams to ship faster. Less friction means doing what the team was already going to do anyway, but faster.

[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.

[macrael]

I think there are certain types of boilerplate that used to be truly onerous that are now much less so because of types. If there are 3 different files that need to be updated to add a file, and forgetting one is only going to error at runtime (maybe even only if you're exercising that new field) that's horrible. But 3 files that require updating where the code won't compile until you've added all three is way way less of a problem.

[tlrobinson]

> But 3 files that require updating where the code won't compile until you've added all three is way way less of a problem.

I think this is only really possible in a relatively small subset of programming languages, even among those with static typing. At a minimum it seems like it would require a type system that didn't allow optional properties (by default) and did distinguish between nullable and non-nullable types.

Unless I'm missing something. Would love to see some examples of this done right. Or at least examples of languages you've done this in.

[macrael]

Optional types can get you for sure. I've been doing this with typescript and it's been alright. Prisma -> my domain model -> ApolloServer

[senorrib]

This is exactly my experience. Glad to see I'm not alone, sad to hear that it's so common out there.

[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