Browser support?

[gtamas]

This doesn't work in browser currently. Are there any plans for adding browser support?

As I see it, the main problem is the grpc dependency, since it relies on the C++ addon. But Grpc is supposed to work fine in the browser too:

https://grpc.io/docs/tutorials/basic/web/

So can we expect browser support to be added anytime soon?

Btw: great job with the lib! :) Nice API!

[connor4312]

Thanks for the kind words :)

I'd be happy to accept any PRs for this. This hasn't been a super high priority for me, but I recognize that being able to communicate directly with etcd may be very useful for e.g. browser-based management interfaces. I'll look into it, but no promises.

For others, please 👍 this issue if it's something you'd like to see prioritized.

[gtamas]

@connor4312

Any updates about this? Btw what benefits gRPC provides over REST / HTTP? As far as I know, ETCD has a REST API too, but using RPC is faster. But on the other hand, it adds this heavy dependency (grpc) and it requires node-gyp. Are there any other benefits?

[pauliusuza]

Might be relevant: https://github.com/mixer/etcd3/pull/123

[connor4312]

I looked into this a bit more this weekend, and documenting here half for myself when I pick this up again. grpc-web is the complement to grpc-js that works on the web. In theory, we could abstract any differences in the ConnectionPool or allow injecting the grpc implementation which would let us have a "browser" entrypoint that injects grpc-web.

The snag I hit is around how protobuf objects are managed. Currently we use grpc-loader, which reads from a file and creates objects using protobuf, but this is for grpc-js. We can generate web protobuf code via

protoc -I=proto --proto_path=proto --js_out=import_style=commonjs:proto/build --grpc-web_out=import_style=commonjs,mode=grpcwebtext:proto/build proto/kv.proto proto/auth.proto proto/rpc.proto

and for grpc-js, use their wrapper

grpc_tools_node_protoc -I=proto --proto_path=proto --js_out=import_style=commonjs:proto/build  --grpc_out=grpc_js:proto/build proto/kv.proto proto/auth.proto proto/rpc.proto

which would effectively give us nice protoc-generated code for both grpc-js and grpc-web. This also lets us drop some runtime dependencies.

The difficulty is that the JS objects generated by protoc are not very idiomatic -- they are classes, on which you must call things like setFoo(fooValue) to set the property. Currently, throughout etcd3 we create plain objects that match the interface which then get serialized. (And creating these objects from plain objects is not supported protocolbuffers/protobuf-javascript#96) So moving to protoc-generated code is possible, and probably a good goal, but it will be a lot of churn in the codebase.