I wish tRPC could interact with Go app but that's limited to TypeScript.
Take a look at https://github.com/pacedotdev/oto
In my case, we generate a Typescript API client for a React app. Very nice companion to Golang.
161–170 of 223 posts
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,…
Admittedly for the web front end I couldn't find a satisfactory tool so I built typed-graphql-builder (https://typed-graphql-builder.spion.dev/). You do have to run it if your backend schema changes, but not when your queries change as the queries are written in typescript and inferred on the fly. (I should probably write a watch mode for the cli, that should largely take care of the rest of the toil when quickly prototyping)
Earlier quoted context omitted.
For cross-language, I can recommend Fern, which works with OpenAPI http://buildwithfern.com
You can recommend it in what context, from openapi (as they claim https://github.com/fern-api/fern#starting-from-openapi ) or from their ... special ... definition schema? For those wanting less talk, moar code: https://github.com/fern-api/fern-java/blob/0.4.2-rc3/example... -> https://github.com/fern-api/fern-java/blob/0.4.2-rc3/example... Regrettably, I wasn't able to readily find a matching openapi example, likely…
This is good feedback that we need to provide more examples starting with OpenAPI instead of with the Fern Definition. For some context, we convert the OpenAPI spec into a Fern definition and then pass that into the code generators.
If you want to see some real world examples, check out these links:
- https://github.com/vellum-ai/vellum-client-generator/tree/ma... -> https://github.com/vellum-ai/vellum-client-python
- https://github.com/Squidex/sdk-fern/tree/main/fern/api/opena... -> https://github.com/Squidex/sdk-node
Worth calling out that you can go from the Fern Definition -> OpenAPI anytime to prevent lock in.
We’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…
One thing that worked surprisingly well: codegen TypeScript types from your database and use those in your API schema.
Heya! Creator of tRPC here, just wanted to drop by and say thanks for all the love ♥
This is the first time I’ve even seen an emoji in an HN comment. What?! Unicode Character “♥” (U+2665) ♳
Earlier quoted context omitted.
Thank you for the suggestions! I am specifically looking to optimize frontend-to-server communication, so WebSocket is a must. Is there some way I could inject a custom transform function between TRPC and the WebSocket? I could copy the existing WebSocket link and add my transform in there, but it would of course be easier if I could just do my own wire handling with the existing code. Essentially I'd like to inject…
Update: I was able to get this working by wrapping WebSocket and WebSocketServer! The API surface for the wrapper seems to be pretty minimal. If I do use TRPC in the rewrite of the embedded server, I'll implement a custom message scheme as an alternative and benchmark them. Here's a gist with the wrappers (transporting the data as a JSON array instead of a dict): https://gist.github.com/TimonLukas/7c757a3b234344ad71e…
This will reduce message size quite a bit, since the data isn't sent as:
{ "id": 3, "method": "subscription.stop" }
but instead as: [3,1]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.
our problem with tRPC is that we don't have an easy to way to test the endpoint in say, curl or postman. there is a “REST Wrapper” project out there, but learning that was even needed was … fun I don't mind it, we found other ways to test Out of curiosity, how do you add a memcache to tRPC if you dont want to write directly to the prisma database
Earlier quoted context omitted.
This is the overlooked advantage of a schema (e.g. in GraphQL): it forces you to think about the data types and contract, and serves as a good way to align people working on different parts of the code. It also scales to other languages besides TypeScript which helps if you ever want to migrate your backend to something else or have clients in other languages (e.g. native mobile apps in Swift, Kotlin, etc).
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…
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.
our problem with tRPC is that we don't have an easy to way to test the endpoint in say, curl or postman. there is a “REST Wrapper” project out there, but learning that was even needed was … fun I don't mind it, we found other ways to test Out of curiosity, how do you add a memcache to tRPC if you dont want to write directly to the prisma database