[HN Gopher] Show HN: Pbkit - Protobuf toolkit written in Deno/Ty...
___________________________________________________________________
Show HN: Pbkit - Protobuf toolkit written in Deno/TypeScript
Author : disjukr
Score : 61 points
Date : 2022-04-04 05:55 UTC (1 days ago)
(HTM) web link (pbkit.dev)
(TXT) w3m dump (pbkit.dev)
| byteski wrote:
| its good to see all cool projects that are written in deno and ts
| lf-non wrote:
| If you are considering protobuf for browser <-> server
| communication (as opposed to server <-> server) a good
| alternative is Twirp [1] by twitch. Like gRPC it uses protobuf
| for API schema, but unlike gRPC it works out of the box with HTTP
| 1 without needing any proxies.
|
| I found both the golang server integration and the typescript
| client generated to be idiomatic and easy to use. There are
| community integrations with other languages too - but ymmv.
|
| [1] https://twitchtv.github.io/twirp
| tommiegannert wrote:
| Just be aware of the lack of streams:
| https://github.com/twitchtv/twirp/issues/3
| jenny91 wrote:
| Any advantages to gRPC-web? We've been using it for a while and
| it's a bit clunky, but it works.
|
| We stick envoy in the middle for gRPC-web <-> gRPC; what do I
| need for Twirp?
| lf-non wrote:
| It works oob - the browser can directly talk to twirp
| service.
|
| I used it because I basically wanted end-to-end type-safety
| without any infrastructure overhead and additional decode-
| encode hops in betweeen.
| jenny91 wrote:
| Ah, but it's not gRPC compatible then; just very similar
| and uses the same proto syntax for services and messages?
| stephen123 wrote:
| Nice.
|
| We are using (https://github.com/whisklabs/grpc-
| ts)[whisklabs/grpc-ts]. We saved %80 of our bundle size by
| changing from grpc-web. Those generated proto-js files were big!
| tommiegannert wrote:
| Broken formatting. Link is https://github.com/whisklabs/grpc-ts
| disjukr wrote:
| Our company uses gRPC/Protobuf intensively.
|
| I'm a web front-end engineer, and one day my boss informed the
| client engineers that the API provided by the back-end would be
| in the form of gRPC only.
|
| To use the gRPC/Protobuf stack in the web frontend, there were
| two options: protoc and Protobuf.js. Protoc generated JavaScript
| code old-schooled and required native dependencies, and
| Protobuf.js was problematic for us at our scale.
|
| And we are a company that makes mobile apps that use webviews a
| lot. When webviews communicate with natives, they communicate
| using the interface defined by the protobuf service schema. The
| service code generated by the existing protobuf tooling is
| tightly coupled with gRPC, and it was necessary to make this part
| into a structure that can be easily replaced.
|
| So we started making our own protobuf compiler, and while
| building the compiler, we also made a package manager, VSCode
| extension, and Chrome Devtools.
|
| As far as I know, there is no tool that properly supports
| functions like Go to Definiton in VSCode extension. We have
| implemented this function properly, and we plan to implement
| other functions using our language server such as autocomplete
| someday.
|
| Now we've stripped out all of the Protobuf.js code, which was a
| big part of our biggest product, and rewritten it with Pbkit.
| mhoad wrote:
| There is another pretty good solution for this that will allow
| your front end to stick with JSON and keep your backend as gRPC
| only which is to stick envoy in front of the gRPC services and
| use a filter to translate between the two which is what you are
| already doing except you are doing gRPC-web to gRPC right now
| since gRPC in the browser isn't currently possible but that
| should be changing hopefully before too long with technologies
| like WebTransport (https://web.dev/webtransport/).
|
| I'm only familiar with Google's cloud stack but they have
| basically managed versions of this already in the form of their
| Cloud Endpoints and API Gateway products that will handle all
| of this for you out of the box. I can't speak to AWS or others
| but like I said at the end of the day it's really just an Envoy
| filter doing the heavy lifting.
|
| But in short you can 100% write gRPC only backends but still
| expose a JSON / REST API and nobody has to know anything to do
| with gRPC and you can just wait for the browser technologies to
| catch up in the meantime and make the transition when you're
| ready.
| idbehold wrote:
| 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. Its 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.
___________________________________________________________________
(page generated 2022-04-05 23:02 UTC)