ts-protoc-gen VS protobuf-ts

:::note When using remote APIs, we often have the possibility to generate the types automatically from a JSON schema for REST APIs, from protobuf files for gRPC-based APIs, from a database schema, etc. You might even be using an external API through an SDK that already provides you with all types. In such cases, the creation of specialized Error classes is not mandatory. However, it might still be a good idea to do so to provide application-specific errors rather than bubbling up 3rd-party low-level errors. For such cases, the upcoming Ecma TC39 proposal for Error Cause is useful as it allows to chain errors. Polyfills exist: Pony Cause or error-cause. :::

DX for front or back end? The beauty of tRPC is that the types are derived/inferred from the backend runtime code (like, as you type). It would be nigh impossible to do that with grpc(-web) using proto files as the source of truth.

It's possible there's a project out there which could automatically produce proto files from something like zod, json-schema, etc. which could be directly interpreted by TS to provide similar (as you type) DX while still allowing some other language backend to consume the derived proto files (though the DX there would be less than ideal).

If you're just looking for similar TS clients/interfaces for grpc-web then I'd recommend https://github.com/timostamm/protobuf-ts which operates on plain JS objects (no new MyMessage().serialize(), instead the code generator mostly produces TS interfaces for you to work against: const myMessage: MyMessage = pojoConformingToInterface; const binary = MyMessage.toBinary(myMessage);)

https://github.com/timostamm/protobuf-ts (RpcMetaData) https://github.com/timostamm/protobuf-ts/blob/main/MANUAL.md

The second big difference is that we now have auto-generated client and server stubs. For this task, I chose to use buf and the protobuf-ts plugin in order to generate idiomatic Typescript classes and objects. Not only do these classes describe the types we'll use in the server and client, but also includes the actual gRPC implementations used to serialize and send messages back and forth across the wire.

I wouldn’t use grpc with web if you can avoid it. If you’re looking for a ts protobuf library I can recommend this one https://github.com/timostamm/protobuf-ts

https://github.com/timostamm/protobuf-ts looks interesting too.

I'd recommend looking into protobuf-ts (Timo from Buf) or protobuf-es (Buf maintained).

Use a GRPC library for frontend, assuming you want to go with Typescript take a look at https://github.com/timostamm/protobuf-ts Frontend frameworks like Angular/React/Vue don't define what and how to implement backend communication. You can use what you want and how you want it.

And there's also this which is by the same author but came before it: https://github.com/timostamm/protobuf-ts

The latter has code-generation for services and has various transport packages for twirp, grpc, and grpc-web.

This looks very interesting! Anything that can move people away from protobuf.js (which seems to no longer be maintained and depends on prototype values for "default values" meaning that you can't send deserialized protobuf messages to/from web workers) and the "native" JS codegen by Google (which produces code that is both very slow and a awkward to use) is a win in my book.

We're currently using https://github.com/timostamm/protobuf-ts which has been fantastic. It's codegen is dependent on the protoc binary as it is implemented as a protoc plugin, but the code it generates passes the protobuf conformance tests. The generated code also outputs plain objects when deserializing protobuf messages which means it works perfectly when sending stuff to/from web workers. It also has grpc, grpc-web, and twirp clients.