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

181–190 of 223 posts

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

#181

Post by senorrib »

calebio wrote: post #178
macrael wrote: post #173

Earlier quoted context omitted.

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.

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

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

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

#182

Post by johnmorrison »

ShadowBanThis01 wrote: post #176
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 just checked out the Zod intro pages but I still don’t know what problem it’s trying to solve. What is it adding to TypeScript (which I am not conversant in either)? Thanks for any insight!

runtime

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

#183

Post by weird-eye-issue »

clintonb wrote: post #94
weird-eye-issue wrote: post #20

I've had lots of bugs and types would have very very rarely fixed them

Okay…go fix your non-type-related bugs.

They are things that pop up during production usage from primarily logic errors...

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

#184

Post by ShadowBanThis01 »

johnmorrison wrote: post #182
ShadowBanThis01 wrote: post #176

Earlier quoted context omitted.

I just checked out the Zod intro pages but I still don’t know what problem it’s trying to solve. What is it adding to TypeScript (which I am not conversant in either)? Thanks for any insight!

runtime

"Runtime" is not a problem.

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

#185

Post by macrael »

calebio wrote: post #178
macrael wrote: post #173

Earlier quoted context omitted.

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.

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

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.

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

#186

Post by welder »

haney wrote: post #150
welder wrote: post #106

Earlier quoted context omitted.

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.

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

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

#187

Post by squishy47 »

we're using trpc at work and it's quickly becoming the default for gateway apis built for specific frontends. Everyone seems to love it, and when combined with Zod it allows us to iterate super quickly as we pretty much only have to think about business logic as schema properties can easily be shared. though my favourite feature is zod transforms, meaning a iso date string can be validated and transformed into a DateTime object before it gets to the business logic.

also it means we can remove the npm library of types that was previously used to sync types between FE/BE (for this reason alone i love it really)

I found the Docs somewhat lacking when i was trying to get the first project going but now I've used it for 6 months and i don't need to look at the docs it's been great. (remember to have exactly the same versions installed on the FE/BE and the same tsconfig makes it easier too, spent too long on these obvious fixes... :P )

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

#188

Post by ushakov »

tough wrote: post #102
ushakov wrote: post #86

Earlier quoted context omitted.

If you use Server Actions, you can just call a server function from your frontend directly, no need for middleware like tRPC https://nextjs.org/docs/app/building-your-application/data-f...

Thank you I only briefly read about them before and didn't consider them properly. Will try out calling the database directly there, but I kinda liked how with tRPC I can add validation/auth checks etc/ will have to see how I develop my own strategy for that w server actions.

You can use zact for that

https://github.com/pingdotgg/zact

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

#190

Post by nrclark »

tshaddox wrote: post #148
spankalee wrote: post #112

Earlier quoted context omitted.

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.

> 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?

Post reply on HN