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

91–100 of 223 posts

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

#91

Post by matthewfcarlson »

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 also recent did a personal project that uses tRPC and Zod and I agree that it was a fantastic experience. It also makes writing unit tests way easier.

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

#96

Post by marksomnian »

threatofrain wrote: post #83
hu3 wrote: post #68

Earlier quoted context omitted.

I'll bite. With tRPC, changing an attribute of a class in your backend immediately tells you what broke in the frontend in your IDE. No need to recompile or regenerate anything. Also, when developing your frontend, you'll have immediate autocomplete. Again without code generation or compilation. That alone should save you dev time and prevent a ton of frontend bugs.

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 means that breaking API changes can fail CI and never make it into production.

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

#97

Post by marksomnian »

Timon3 wrote: post #39
chaosite wrote: post #33

Earlier quoted context omitted.

Why not just gzip the data? It might not beat a bespoke hand-crafted protocol that minimizes message size, but your use of the word "negotiate" makes me think that that's not what you're taking about...

The embedded device the server is running on has a very weak CPU. Since I'm trying to optimize throughput this would have quite an impact. It's fine if the first few messages are slow, the speed just has to pick up after initialization is done, which is why negotiation is okay for me. So e.g. the client requesting IDs for every method on first connection would be fine, and would keep complexity down.

I imagine you could write a custom tRPC link to send the data over something like MQTT which may be better for an embedded client - there's prior art in the likes of electron-trpc, showing how tRPC could be adapted to non-HTTP transports. Not sure how that interacts with the JSON-RPC bits of the subscription protocol though, if there's no way around it then plain MQTT may be better suited to your use case.

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

#98

Post by pjmlp »

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…

Only obscure to developers living in the present, without caring about learning where we come from, or presenting novel ideas without proper research.

Android Binder, XPC, COM and gRPC are yet again another set of IDL quite present in current times.

JSON? I thought everyone was using YAML now. /s

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

#99

Post by dsinghvi »

marksomnian wrote: post #88
janosd wrote: post #36

I find it really sad that these efforts always stop at working in language X, but no formal specification exists that would make it possible to create an interoperable version in a different language. I love TypeScript, but for various reasons one may need a different backend language on the server side. Yes, OpenAPI is a thing, but I have yet to see an OpenAPI spec + code generator that works out of the box and does…

I think part of why tRPC shines is because it's tightly coupled to TypeScript (and especially Zod, its schema validation library of choice - many of its features map 1:1 onto TypeScript concepts that don't exist in many other languages), which means it can avoid many of the issues that OpenAPI generators have. I'd also like to see a good TS-first OpenAPI client - Fern [0] is probably the closest I've seen. In general…

:wave: Hey Mark -- I'm one of the primary contributors to Fern.

+1 to your comment about how needing to support multiple languages results in not being able to leverage certain language specific features. We've tried the best to manage the trade-offs here, but there's a limit to what you can do.

If you have feedback on how we can improve the TypeScript client, feel free to comment here or create an issue on our repo (https://github.com/fern-api/fern)!

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

#100

Post by RadiozRadioz »

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

What's the point of the middle layer? Seems like an extra step and a language change for no reason. Why not just expose HTTP from your Rust stuff?
Post reply on HN