4 ms·
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 nati
by spion 3y ago
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)
- zukzuk 3y agoUse 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) <--tRPC--> (TS thin backend)] <--gRPC--> (Rust service) This is a bit awkward, but honestly worth it for what you get with tRPC. One thing that took some getting used to is with tRPC the line between "client" and "server" gets blurry, which makes me uncomfortable for all sorts of reasons but in practice works well enough to make it not worth worrying about for now.
- RadiozRadioz 3y agoWhat'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?
- zukzuk 3y agoBecause you lose all the stuff that’s nice about tRPC. The experience of building a tRPC app is very different from building an app that talks to a traditional REST API. The front and back end with tRPC are very tightly bound. In a way the backend part of your tRPC app becomes the real consumer of your actual API.
- RadiozRadioz 3y agoOkay. I see 3 main benefits of the tRPC experience. 1. You don't need to manually write HTTP routes on the server side. 2. You don't need to manually write request code on the client side. 3. There's a type contract between both. I don't see how this "thin server" approach helps with any of these. 1. You're no longer writing HTTP routes, but instead you're writing gRPC. You haven't eliminated the work, you've just changed the technology. If you happen to be integrating with a pre-existing gRPC deployment, why re-invent the wheel with custom TS code instead of using one of the many gRPC->HTTP transcoders? 2. Modern web frameworks have so many abstractions on this pattern that it's a non-issue at this point. 3. Your thin server is effectively a mapper from gRPC to HTTP endpoints. That's the type of thing you can build a spec from. If you've used a transcoder and have a spec, you can codegen your client library with the correct types. I think tRPC works best for making highly cohesive full stack apps. Using it as a middleman for your backend seems weird to me.
- nprateem 3y agoWhy not just expose grpc via grpc-web with the envoy proxy?
- spion 3y agoI'm honestly pretty happy with TypeGraphQL. TypeGraphQL works code-first and lets you integrate request-scoped DI for resolvers, which makes writing more complex resolves significantly more pleasant. 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/ 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)
- deleted 3y ago[deleted]
- ssijak 3y agoThere are more important problems to solve when trying to boot up a self-sustaining startup or project than rewriting your app in a different technology for no apparent reason.
- spion 3y agoThere are very good reasons to go native for a mobile app. React-native can be a huge time sink depending on what you want to do with the app.