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

131–140 of 223 posts

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

#131

Post by graftak »

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 there’s always too many edge cases.

Lots of room for improvement.

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

#132

Post by replygirl »

alexdotjs wrote: post #126
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.

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)

is it git?

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

#133

Post by thinkingkong »

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.

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.

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

#134

Post by dclowd9901 »

Swizec wrote: post #113
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.

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.

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

#135

Post by scottmas »

jitl wrote: post #7

We’ve use an API style similar to tRPC at Notion, although our API predated tRPC by 4 years or so. You can build this kind of thing yourself easily using Typescript’s mapped types, by building an object type where the keys are your API names, and the values are { request, response } types. Structure your “server” bits to define each API handler as a function taking APIs[“addUser”][“request”] and returning Promise . T…

This is the way. tRPC adds unnecessary complexity over simply inferring types. My theory is that no well maintained and promoted library adopting this approach has emerged, and that’s why you don’t see it discussed very often.

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

#136

Post by dclowd9901 »

jitl wrote: post #7

We’ve use an API style similar to tRPC at Notion, although our API predated tRPC by 4 years or so. You can build this kind of thing yourself easily using Typescript’s mapped types, by building an object type where the keys are your API names, and the values are { request, response } types. Structure your “server” bits to define each API handler as a function taking APIs[“addUser”][“request”] and returning Promise . T…

Yeah, I’m reading their sample code and wondering if this is just type-imbuing wrappers on top of XHR calls. It even asks you to provide the generic argument in the invocation (this sucks for trying to keep your dependency tree in order).

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

#137

Post by wrs »

nerdponx wrote: post #69
pjmlp wrote: post #54

Earlier quoted context omitted.

> I've never seen IDL before but I looked up some examples... Proving my point. Search for Sun RPC, DCE RPC, XDR. Take note when they came up, and everything in between until today.

Yes, but those systems have been obscure and uncommon for longer than a lot of today's programmers were even in the field. In the intervening time we all standardized on JSON and rediscovered or reinvented similar concepts all using JSON. Fine. It's great to understand and learn from prior inventions, but it's not like we're all going to switch back to IDL. Consider that JSON being ubiquitous immediately makes it eas…

That’s an interesting statement, because from my vantage point “longevity” seems to be way, way down the priority list for pretty much any technology in JavaScript world. (The major exception being pure JSON.) It feels like if you open any JS codebase from more than 18 months ago, half the libraries will be deprecated or abandoned (not just the version, the entire library). Major patterns and frameworks reinvent themselves incompatibly on a biannual basis.

The purpose of an RPC IDL (protobuf being a “modern” example) is that you define the interface and encoding in a way that will still be functional when your “standard language” is long forgotten or unrecognizably different.

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

#138

Post by dbbk »

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

SPA web-apps still have long-lived sessions

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

#139

Post by yieldcrv »

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.

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

Post reply on HN