4 ms·
Can I ask a naive question? What does this get me that gRPC + Protobuf to generate a Typescript client wouldn't? Edit: Ah. I see, you can use Typescript to de
by ctvo 4y ago
Can I ask a naive question?
What does this get me that gRPC + Protobuf to generate a Typescript client wouldn't?
Edit: Ah. I see, you can use Typescript to define the IDL vs. learning Protobuf, Smithy, ...
Not sure I would take the trade-off. I like having the option of using something other than Typescript for my back-end. The dev experience isn't compelling enough for me. Contract changes are not an area I iterate on so often that a small delay in re-generating the client from an IDL causes me to grab for this dependency.
- azangru 4y ago> What does this get me that gRPC + Protobuf to generate a Typescript client wouldn't? Have you tried running gRPC in the browser? How was the experience?
- ctvo 4y agoI have. It wasn't great, but it worked, and that was years ago. Is that the reason, though? tRPC generates a nicer client when targeting the browser?
- azangru 4y agoYes, this is my understanding. If the browser client and the server are both written in typescript, tRPC has a very attractive story of bridging the two. No protobufs though; so whatever performance wins gRPC brings, are absent from the tRPC story.
- thinkingkong 4y agoThe big item is having no build step. With gRPC even no matter how fast your codegen is, it still needs to execute. With tRPC the return types from the routers are all automatically derived from whatever the mutations or queries return.
- k__ 4y agoHow does a TypeScript based codebase not have a build step?
- thinkingkong 4y agoIt depends how you're running the application but at _development_ in your IDE no build is required between the time you define your controller return and then switch into your react code.
- rcfox 4y agoI'm currently working on a project with Typescript and gRPC. It's mostly great, but I'm somewhat disappointed with the generated code. The frontend and backend get code generated differently. The backend is all interfaces (which, through some Nestjs magic get translated into protobufs) and the frontend is all objects. So on the frontend, you're expected to write: const message = new MyRequest().setName('Bob').setFoo('bar'); On the backend, you'd just write: const message = { name: 'Bob', foo: 'bar' } It's not a big deal, but it's weird. The backend ends up being more/overly strict about all values being set when you might just be fine with the default zero/empty values. Also, using a `oneof` field is correctly typed on the frontend as myfield: TypeA | TypeB | TypeC` But the backend gives you myfield: {a: TypeA | undefined, b: TypeB | undefined, c: TypeC | undefined} For a future project, I'd look into buf or Connect instead of the default gRPC code generators, but for now, I just need to get stuff done.
- tczMUFlmoNk 4y ago> Also, using a `oneof` field is correctly typed on the frontend as myfield: TypeA | TypeB | TypeC But what about when the `oneof` has multiple variants with the same base type? Like: message User { oneof contact_info { string email = 1; string phone_number = 2; } } Does this get compiled down to `contact_info: string | string` on the frontend? How do you tell which variant was used without encoding the discriminant?
- mattwad 4y agoI tried gRPC with Typescript once, and we needed transformers to transform gRPC to something usable - there's no optional fields in the v3 version for example. So we ended up with an extra layer on reading and writing to it, which was hard to test thoroughly. My learnings were that gRPC is for compressing data, not type-safety. The type-safety is kind of just a necessity to get the compression to work, but it is not very expressive.