Is it just me, or is this over engineered? Brings me back to SOAP services and WSDLs.
tRPC – Build and consume typesafe APIs without schemas or code generation
101–110 of 223 posts
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#102Earlier quoted context omitted.
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...
Thank you I only briefly read about them before and didn't consider them properly.
Will try out calling the database directly there, but I kinda liked how with tRPC I can add validation/auth checks etc/ will have to see how I develop my own strategy for that w server actions.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#103Telefunc is another alternative without the boilerplate where on the frontend you can just import and execute the backend functions remotely. https://telefunc.com/
Compared with tRPC: https://github.com/brillout/telefunc/issues/9
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#104I've used tRPC and Next.js for a couple of personal projects and it's been a great experience. Hard to beat on iteration speed, especially when used with a pre-configured template like Create T3 App: https://create.t3.gg/ .
Does it now work properly with Next 13 and server components?
I'm using it with Next 13, but not using the new experimental app folder yet. No issues yet.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#105I'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.
Care to elaborate further? I've been building on top of trpc and even for inter service communication we use it
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#106I'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.
Having the opposite experience with it as a small team, and I can see how it would work great in my past large teams. I bet you're gonna have the same complaints about any API you use not just tRPC (junior developers not thinking about interfaces).
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#107I'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.
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).
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#108We’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…
Similarly, we built a typed-client for inter-service communication using lambdas at Robocorp.
The requests and responses are inferred from the interface (published following semver) defined in Zod (including the errors that are following HTTP-like conventions: 401, 409…).
It also includes “hooks” for pre and post processing on the server side (effectively middlewares)
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#109Earlier quoted context omitted.
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.
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 a custom respond[0] encoder and a custom parseMessage[1] decoder, and same for the client.
[0]: https://github.com/trpc/trpc/blob/main/packages/server/src/a...
[1]: https://github.com/trpc/trpc/blob/main/packages/server/src/a...
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#110Dropping in a tRPC use case that I've really got a lot of mileage out of: communication between the Electron main and renderer processes using https://github.com/jsonnull/electron-trpc. Traditional Electron IPC is hard to do type safely, which electron-trpc solves, and the react-query integration (meaning you get automatic type-safe hooks to issue the requests) is really nice.