Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

tRPC – Build and consume typesafe APIs without schemas or code generation

trpc.io

Post reply on HN
Print view View original

141–150 of 223 posts

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#141

Post by simonbw »

pennaMan wrote: post #117
skybrian wrote: post #114

I'm wondering how they handle version skew and migration. Fields have a lifecycle. When they're introduced, no clients or servers know about them. Clients and servers aren't restarted all at once. They won't have the same version of the types. Data will be written using one version of a type and read using a different version. If you can guarantee all binaries, running programs, and data gets upgraded (no persistent…

That's why it's a tool for web apps

Web apps can still have the problem of the server and client getting out of sync.

1. Plenty of people deploy their frontend and their backend separately. 2. Even if frontend and backend are deployed at the same time, there's still the case where the user has the old version of the client loaded in their browser as a new backend gets deployed. I've seen some web apps tackle this by periodically checking if a new version is available and either refreshing the page or prompting the user to refresh the page.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#142

Post by wruza »

bborud wrote: post #51
wruza wrote: post #29

Surprised this thread isn’t full of scary RPC stories and SOAP CORBA under your bed at night. Either the wave is gone or it’s just a little early.

I'm not too surprised. Most people for whom TypeScript is an option won't have been exposed to generations of RPCs that fail to deliver simplicity. So it isn't going to be on their radar. I've been using gRPC and REST'ish+JSON APIs for years now and what I find puzzling is that REST+JSON tends to mean a lot more work, less pleasing code than gRPC, and yet people prefer it. Not because it leads to simpler, better, fas…

I agree that sticking to just a library may be not a good choice. Some standard would be better. But few last times I discussed it, some folks just slapped RPC stigma on everything, even if it was just your regular REST-y-ish calls underneath. That’s absurd. POST json receive json back is okay. Wrap it into an `await server.()` call and now it’s an RPC mudball. The current top commenter is removing tRPC for tight coupling. I wonder what prevents them from tight coupling over http, or over just function calls when on the same “side”. It’s a mindset that they are removing, not a specific technology.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#143

Post by johnmorrison »

graftak wrote: post #131
johnmorrison wrote: post #82

I love tRPC, it's by far the best fullstack DX I've ever seen and has such a brilliant API especially when combined with Zod. Zod and tRPC are some of the most important projects in the future of TS imho, I think we're gonna see a beautiful bloom of tRPC inspired DX across the TS space in coming years. Two projects already have clearly have tRPC DNA attacking different use cases are Ping's UploadThing ( https://githu…

I don’t really like Zod at all, it has very finicky and verbose types/generic params and it’s object generic won’t allow you to pass a data type, but instead you must pass zods own schema types as properties which are very messy and unintuitive. Another annoyance is that the type of validation errors varies depending on what kind of schema you’re checking against. This makes it unpredictable to handle errors and ther…

I don't disagree (not that I feel the same level of annoyance, on balance I love Zod for the time it saves me) but what would you recommend as an alternative?

The new valibot.dev looks cool but I haven't tried it yet.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#144

Post by johnmorrison »

killthebuddha wrote: post #125
johnmorrison wrote: post #82

I love tRPC, it's by far the best fullstack DX I've ever seen and has such a brilliant API especially when combined with Zod. Zod and tRPC are some of the most important projects in the future of TS imho, I think we're gonna see a beautiful bloom of tRPC inspired DX across the TS space in coming years. Two projects already have clearly have tRPC DNA attacking different use cases are Ping's UploadThing ( https://githu…

Zod is...so freaking great. I'm feeling kind of hyperbolic at the moment, so I'll even go so far as: for a certain style of programming, adding Zod to a codebase is as big of a win as adding TypeScript.

Absolutely. Zod is to the runtime what TypeScript is to the IDE.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#145

Post by johnmorrison »

epolanski wrote: post #120
johnmorrison wrote: post #82

I love tRPC, it's by far the best fullstack DX I've ever seen and has such a brilliant API especially when combined with Zod. Zod and tRPC are some of the most important projects in the future of TS imho, I think we're gonna see a beautiful bloom of tRPC inspired DX across the TS space in coming years. Two projects already have clearly have tRPC DNA attacking different use cases are Ping's UploadThing ( https://githu…

I would also recomment effect/core + effect/schema, the pattern of creating typed services starting from schemas is there perfect for people that are more functional-programming leaning.

I saw that a while back, but it seems like a large learning curve and I don't immediately feel much drawing me towards it. Will be keeping an eye on it anyhow.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#146

Post by Swizec »

dclowd9901 wrote: post #134
Swizec wrote: post #113

Earlier quoted context omitted.

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/api…

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.

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.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#147

Post by wruza »

clintonb wrote: post #92
betimsl wrote: post #12

Is there something like this but for JavaScript?

Not sure if you’re trolling. The whole point of this is type safety which requires…types.

It’s not the whole point. Making async calls, handling errors as usual and subscribing on channels has better ergonomics (DX) than bare requests, http streams or websockets.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#148

Post by tshaddox »

spankalee wrote: post #112
miraantabrez wrote: post #107

Earlier quoted context omitted.

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

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 inter…

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.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#149

Post by haney »

epolanski wrote: post #119
haney wrote: post #87

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.

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.

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.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#150

Post by haney »

welder wrote: post #106
haney wrote: post #87

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.

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

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.
Post reply on HN