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

121–130 of 223 posts

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

#121

Post by killthebuddha »

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…

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

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

#122

Post by MrJohz »

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…

Do you know of anything in this region for MongoDB? The two big problems there seem to be type-safe data CRUD, but also migration of data. I see people referencing Mongoose a lot, but that seems like it's a big downgrade from Zod/TS in terms of type safety.

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

#123

Post by malkia »

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 feel that RPC mechanisms that are too closely tied to a given language are a waste of time" - THIS RIGHT HERE! - The whole point is to allow people using different languages to collaborate - your analysts using python/R should be able to talk to your Java/C++/Rust/C#/Go folks and web-frontends (and server sometimes) Typescript/Javascript/etc.

One of the worst example (in the past) was the python pickle. People have overused it, and it's not even compatible between some python releases. There are many other examples - where something works really neat, but only for that language, or even that language major or even just minor release.

There is protobuf, cap'n'proto, flat buffers, fidl, thrift, etc. - many better choices than just one that works only for your language.

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

#124

Post by nprateem »

zukzuk wrote: post #57
spion wrote: post #53

So what do you do when you decide that you don't want to use JavaScript anymore on either side of tRPC? (switch to something else on the server, or write a native mobile app, etc)

Use TypeScript instead? (semi-joking) The way I've been approaching this lately is TypeScript on the frontend, then a thing TypeScript layer on the backend (via Deno), with those two pieces connected with tRPC. The real backend guts are in Rust (or whatever), and the backend tRPC layer talks to the Rust stuff with gRPC. So something like this: [(TS web client) (TS thin backend)] (Rust service) This is a bit awkward,…

Why not just expose grpc via grpc-web with the envoy proxy?

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

#125

Post by killthebuddha »

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.

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

#126

Post by alexdotjs »

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)

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

#127

Post by [deleted] »

marksomnian wrote: post #96
threatofrain wrote: post #83

Earlier quoted context omitted.

Wouldn't optional code generation be rather desirable? Then you don't need a monorepo, which a lot of people don't do.

It slows down the iteration cycle - when you make a change to your API definitions you'd need to push the change to either a schema repository or into production, then regenerate the API - at which point, if you've accidentally introduced a breaking change, your frontend is already broken - you can work around this with CI that detects breaking changes, but it requires a fair amount of work. Having them in a monorepo…

[deleted]

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

#128

Post by killthebuddha »

MrJohz wrote: post #122
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…

Do you know of anything in this region for MongoDB? The two big problems there seem to be type-safe data CRUD, but also migration of data. I see people referencing Mongoose a lot, but that seems like it's a big downgrade from Zod/TS in terms of type safety.

I've never used it for Mongo, but Prisma is a pretty great type-safe ORM that supports Mongo: https://www.prisma.io/docs/getting-started.

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

#129

Post by ssijak »

spion wrote: post #53

So what do you do when you decide that you don't want to use JavaScript anymore on either side of tRPC? (switch to something else on the server, or write a native mobile app, etc)

There are more important problems to solve when trying to boot up a self-sustaining startup or project than rewriting your app in a different technology for no apparent reason.
Post reply on HN