6 ms·

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 develop

by haney 3y ago

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.

macrael 3y ago
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 3y ago
  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.
  - senorrib 3y ago
    This is exactly my experience. Glad to see I'm not alone, sad to hear that it's so common out there.
  - macrael 3y ago
    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 3y ago
      > 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 3y ago
        Optional types can get you for sure. I've been doing this with typescript and it's been alright. Prisma -> my domain model -> ApolloServer
random_kris 3y ago
Care to elaborate further? I've been building on top of trpc and even for inter service communication we use it
welder 3y ago
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 3y ago
  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 3y ago
    > 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.
miraantabrez 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      > 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 3y ago
        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”.
deleted 3y ago
[deleted]
Swizec 3y ago
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 3y ago
  +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 3y ago
  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 3y ago
    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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
        If you’re in TS world then you can export the Zod schema that your tRPC queries/mutations are using.
alexdotjs 3y ago
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 (alex@trpc.io)
- replygirl 3y ago
  is it git?
thinkingkong 3y ago
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.
yieldcrv 3y ago
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
- vendiddy 3y ago
  There are libs like ts-rest which I found to be less magical and easier to test.
- JCharante 3y ago
  I use trpc playground. It takes a few lines to setup.

by haney 3y ago

macrael 3y ago

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 3y ago
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.
- senorrib 3y ago
  This is exactly my experience. Glad to see I'm not alone, sad to hear that it's so common out there.
- macrael 3y ago
  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 3y ago
    > 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 3y ago
      Optional types can get you for sure. I've been doing this with typescript and it's been alright. Prisma -> my domain model -> ApolloServer

random_kris 3y ago

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

welder 3y ago

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 3y ago
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 3y ago
  > 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.

miraantabrez 3y ago

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 3y ago
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 3y ago
  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 3y ago
    > 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 3y ago
      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”.

deleted 3y ago

[deleted]

Swizec 3y ago

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 3y ago
+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 3y ago
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 3y ago
  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 3y ago

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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      If you’re in TS world then you can export the Zod schema that your tRPC queries/mutations are using.

alexdotjs 3y ago

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 (alex@trpc.io)

replygirl 3y ago
is it git?

thinkingkong 3y ago

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.

yieldcrv 3y ago

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

vendiddy 3y ago
There are libs like ts-rest which I found to be less magical and easier to test.
JCharante 3y ago
I use trpc playground. It takes a few lines to setup.