Heya! Creator of tRPC here, just wanted to drop by and say thanks for all the love ♥
Thank YOU Alex!
This project has done incredible things for TypeScript
tRPC – Build and consume typesafe APIs without schemas or code generation
81–90 of 223 posts
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#82I 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://github.com/pingdotgg/uploadthing) and our Lusat (https://github.com/lusatai/lusat).
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#83OK, looks great but as a manager and founder of a company that is looking into sponsoring OSS, how does this make me more money?
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.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#84This site used up 2gb of memory when I opened it, and apparently I was near the brink.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#85So is it just TS to TS ?
If it is same language I just had common library implementing all the types for server and client, no need to get any more fancy than that, crossing the language barrier is the problem for type safety.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#86Earlier quoted context omitted.
In server components you can just await in the component itself so you don't need a solution like tRPC.
Could you expand on this? You don't need it, but you certainly can prefer to use it regardless? Hoping react-server-components trpc gets solved soon
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...
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#87I'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.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#88I 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 in my experience, when you take away the constraint of inter-language interop, you get much smoother DX because you can take advantage of language features. A good example would be the lack of native date/time types in JSON - valuable for interop because different languages handle dates differently, but painful when you're going to/from the same language. Web applications are a special case, because the client-side is effectively constrained to either JavaScript or WebAssembly (except you'd still need at least some JS in the latter case), so it follows that you'll get the best DX if you have JS or TS on both sides of the stack, especially if you can set up your project in a way that lets you share code between both. Not always an option, but I've always felt more productive (as a full-stack dev) when I've been using TS on both the client and server, compared to TS on the client and another language on the backend.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#89Surprised 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…
People sticking with REST+Json usually don't want to have a compilation step for the API exchanges layer. That means more validation and worse tooling, but also better legacy and potentially future compatibility, and way easier debugging at any stage.
I feel this is the same debate between scripting languages and compiled languages, both provide different trade-offs and I don't think we'll see one completely disappear at any point in time.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#90I 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 prefer building an OpenAPI-compatible API over tRPC to avoid being stuck on Typescript. I don’t fault the creators of tRPC for their decisions. It’s their project, and they don’t have to build interoperability. You can always use gRPC for that.
I would prefer they focus on doing their one thing well than trying to please everyone only to end up pleasing no one.