Heya! Creator of tRPC here, just wanted to drop by and say thanks for all the love ♥
you are awesome!
tRPC – Build and consume typesafe APIs without schemas or code generation
61–70 of 223 posts
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#62If you wanna take the concept up a notch: https://rakkasjs.org/guide/use-server-side-query
> When it runs on the client, variables from the surrounding scope that you use in the server-side function are captured, serialized, and sent to the server. Since anyone can send any request to the server, you have to validate everything that comes from the surrounding scope. This is mildly horrifying to consider without good tooling support.
On the next iteration, we're planning on providing a `createServerQuery` function which will _not_ capture the closure and return a function that can take an arbitrary number of arguments to be serialized. `createServerQuery` will have a required `validator` option that will also run on the server to validate those arguments.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#63Can I just say ... sigh ... I miss
1) Java remoting itself
2) GWT's "emulation" of java remoting to the client side
It was SO very, very fast (and safe) to add a new backend interaction.
Plus I loved that you could be so evil as to just serialize a java class, send it over RPC, to be executed on the other side. Security nightmare (even though it was fixable if you really wanted to), but damn, you can do absolutely everything with that.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#64I've just started using tRPC, and I'm in love with it so far! I use GraphQL at work, but I always felt like the boilerplate is too much for my hobby projects, and I wasn't really happy with the code-first frameworks that I could find (especially with the ones that support proper Relay integration). Thanks a lot for the creators! Also if anyone is enticed by this, I highly recommend trying it out!
Garph has no boilerplate and comes with Relay out of the box: https://garph.dev
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#65I've personally been using ts-rest for my projects, which is traditional REST but allows one to autogenerate types and API docs from a zod schema. tRPC seems cool, but seems riskier to go with an alternative to REST or GraphQL, especially if you intend to make your API public and/or have multiple consumers of your API.
tRPC is not at all intended to ever be a public API, the way REST or GraphQL is. It's meant to be a tight, private connection between your client and your server.
If you use tRPC in your stack but want a public API, you will almost certainly need to build that out separately, via traditional REST, or GraphQL, or maybe gRPC. This feels all kinds of wrong initially, and there are some obvious and not so obvious disadvantages to this, but honestly it's not all bad when you get down to it.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#66Of course you don’t need schemas or code generation if you are only targeting one language.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#67We’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…
For cross-language, I can recommend Fern, which works with OpenAPI
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#68OK, 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.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#69Earlier quoted context omitted.
OpenAPI, JSON-RPC, and JSONSchema have existed for a pretty long time now. The industry has more or less standardized on JSON for data interchange and parsers/generators for JSON abound in every programming language, so it makes sense to do all this stuff with JSON. I've never seen IDL before but I looked up some examples and it does seem useful for RPC calls. But I'm not exactly eager to switch, it looks like it's m…
> 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 easier to adopt compared to a custom description language. If people actively used IDL today, there would probably be a lot of demand for a JSON variant or subset.
I'd make similar arguments about using JSON vs S-expressions for data interchange, but JSON works well with both Javascript and HTTP and everyone standardized on those, and maps cleanly to basic data structures in just about every modern programming language.
These JSON-based tools are actually very much like Lisp in that both the interface specification and the data are expressed in exactly the same format/language. This is not true of a lot of these older standards, and seems to have been the failed promise of XML.
IDL does look like it maps nicely to typed function calls in most languages, but it lacks the advantage of being expressed in a standard format/language that is already well-supported for other tasks, and seemingly doesn't impose any requirements on how the data itself is transmitted.
For an example of why language/format matters, consider the tool c2ffi (https://github.com/rpav/c2ffi). It generates a JSON description of a C header file. The header file itself is a pain to parse and extract information from. But once you have a tool to do it and put that information in a standard format, you can now build an FFI wrapper in just about any other language in at least semi-automated fashion. It makes the easy parts easier, compared to other systems like SWIG and GObject where the interface format is totally custom and you're mostly reliant on a single implementation to make it all work.
If anything, let's be grateful that the good ideas of the past are being rediscovered and reinvented in a way that might grant them more longevity and broad usefulness than they had in their first life. Did you use IDL? What was your experience like? How would you compare it to something like gRPC?
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#70I'm a big fan of tRPC. It's amazing how it pushed TypeScript only stacks to the limit in terms of DX. Additionally, it made the GraphQL community aware of the limitations and tradeoffs of the Query language. At the same time, I think tRPC went through a really fast hype cycle and it doesn't look like we're seeing a massive move away from REST and GraphQL to RPC. That said, we see a lot of interest in RPC these days a…
Garph is like tRPC but for GraphQL: https://garph.dev For REST APIs there's ts-rest ( https://ts-rest.com ), zodios ( https://www.zodios.org ) and Hono ( https://hono.dev ) If your team uses multiple languages, there's Fern: https://www.buildwithfern.com
+1 for ts-rest
The people on the Discord are very helplful