Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

protobuf-ts relationship to connect-web #356

Open
pquerna opened this issue Aug 4, 2022 · 2 comments
Open

protobuf-ts relationship to connect-web #356

pquerna opened this issue Aug 4, 2022 · 2 comments

Comments

@pquerna
Copy link

pquerna commented Aug 4, 2022

Hello!

Thank you again for this wonderful library.

With the recent announcement of connect-web:
https://buf.build/blog/connect-web-protobuf-grpc-in-the-browser
https://github.com/bufbuild/connect-web

I was wondering what the plans are for this library? Should we consider connect-web to be the defacto replacement / v3 of protobuf-ts?

@jcready
Copy link
Contributor

jcready commented Aug 4, 2022

See #324

@timostamm
Copy link
Owner

connect-web is not a replacement of protobuf-ts, but parts of protobuf-es will be.

connect-web is actually two projects:

  1. connect-web, a code generator for gRPC-web and the Connect protocol
  2. protobuf-es, a code generator for messages and enums

I believe this separation of concerns is actually important to improve protobuf for JS. I've been using protobuf in Go a bit lately, and they have a pretty nice package that makes it really easy to write your own plugins: https://pkg.go.dev/google.golang.org/protobuf/compiler/protogen I believe we need something similar in JS, so that we can move away from monolithic projects like ts-proto and protobuf-ts. If the project cannot generate what you need, you are out of luck. Instead, users should be able to write their own code generators easily.

If you look at the source code of connect-web, that seems to work pretty well. It is really just around 1,600 lines of library code, plus a code generator, and it can evolve independently of protobuf-es.

This change wasn't feasible iteratively. So unfortunately, we are stuck with two code generators that share very similar types. Ultimately, I hope that protobuf-ts becomes a code generator (or suite of code generators?) that uses the base types provided by protobuf-es. Obviously this will require some work to allow a smooth transition - for example, see the points raised by James in the discussion. But in result, it will massively reduce the complexity of protobuf-ts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants