Hacker News Reader

Comment by zukzuk | Hacker News Reader

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) <--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.

View on HN

I'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/). 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)

What'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?

Because 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.

Okay. 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.

Why not just expose grpc via grpc-web with the envoy proxy?

Reply on news.ycombinator.com