renbou / grpcbridge Goto Github PK

To properly test how the routing/balancing works in grpcbridge, a second test service should be written, and the first one updated, so that they have different gRPC service and endpoint names. For example, a clone of the Go-based service can be written in Python, but with the packages changed to testsvc.goapi.v1 and testsvc.pyapi.v1 for example.

Instead of ad-hoc setup of components in main, a semi-generic component in the root package, grpcbridge, should be created, so that it is usable not only from the grpcbridge binary, but also from other packages. It is also a good place where a thorough godoc can be placed regarding how the different components are integrated together in the current setup of proxying to remote services.

To properly end the 0.1.0 milestone, basic pipelines should be setup as part of the grpcbridge refactor.

Having implemented HTTP pattern routing and request transcoding, what's left is to implement the bridging itself. The current gRPC proxy component should be abstracted in the grpcadapter package to allow any incoming stream implementation to get proxied to a connection. Error handling should be implemented similar to gRPC Gateway, with the error getting marshaled just like a normal message would. See https://github.com/grpc-ecosystem/grpc-gateway/blob/882fa790dbf0d15a5c422190181199a2ea1f7aab/runtime/errors.go#L36 for more detail.

Since most of the components already support dynamic creation/closure, it shouldn't be too difficult to support dynamic reloads of the config file and addition/removal of service definitions.

For basic HTTP/WebSocket/EventStream bridging, a router functionally equivalent to the one used in [](https://github.com/grpc-ecosystem/grpc-gateway is needed. Right now it isn't possible to implement through the library itself, since the main httprule component is hidden in internal, so it should probably just be copied into an internal package alongside the license. Using this package for the path-matching it should be possible to implement a router which supports modifications in real-time when updates come via the desc watcher. Perhaps this won't be the fastest way, but it should work decently enough if some template caching is performed to avoid rebuilding the whole handler list each time.

After completing #3 a basic gRPC proxy mechanism can be implemented, with routing to different services based on the discovered endpoints. Routing can be performed by the gRPC service part, without including the method, because gRPC service names are meant to be unique anyways, and this way routing will be more lightweight.

To avoid writing additional services which can be used for demonstration of grpcbridge's functionality, the current Go and Python example services should be rewritten with toy APIs. The current APIs are quite difficult to understand, and it'd be much better for the demo services to perform some actually meaningful logic.

Analogous to the current gRPC proxying implementation, setup an additional WebSocket server & proxy incoming requests. Right now it should also support all kinds of streaming (even unary requests), because I don't see a need to block certain requests from being made using WebSocket. Maybe later it could be implemented using a flag or something of that kind.

For any automatic configuring of the bridge, a basic gRPC service description discovery mechanism is necessary. For now, it will be enough to simply retrieve the available service endpoints using gRPC reflection. Message types aren't needed because for basic protobuf proxying (gRPC proxying, gRPC-Web, etc) since all protos can be unmarshaled as emptypb.Empty with unknown fields preserved (see https://protobuf.dev/programming-guides/proto3/#unknowns, https://github.com/mwitkow/grpc-proxy).

Once the components are relatively usable together after #14, unit tests for the currently present components should be written, mostly with the target of verifying that the components, beside working properly, aren't leaking any goroutines/memory.

Initialize the basic service core in cmd/, which should read in the bridge config from an HCL file, which for now should probably just contain a single services map with specification of service-endpoint, as a form of basic static service discovery. Place the bridge config in the root, so that using grpcbridge as a library feels ergonomic, while the parsing logic can be located in internal.

To implement proxying with support for JSON, query, and path-parameter parsing, the complete proto definitions are required. Right now the reflection client retrieves only service names, and retrieval of complete definitions will need using the file_containing_symbol request from the reflection API. This functionality should be implemented with an option to disable it for cases when it's not needed (gRPC proxying and gRPC web).

SSE/EventSource should be supported as a client interface, specifically for server-side streams. There's no point for supporting it for BiDI/Unary endpoints, because there's no proper interaction which can be built using EventSource anyway. Last-Event-Id, and all other features should also be supported. id/event fields can perhaps be set using fields in the proto message, e.g. event_type, event_id. Note that all of them need to be string fields, since an EventSource is parsed as UTF-8.

Standard: https://html.spec.whatwg.org/multipage/server-sent-events.html#concept-event-stream-last-event-id

An HTTP transcoding bridge should be implemented as a baseline solution for other protocols (WebSocket, EventStream) using the routing implemented in #20. It should support bodies of application/json and application/x-protobuf/application/x-protobuf+text/application/octet-stream content types to allow gradual transition along a path which looks something like:

1. Using REST/JSON API with HTTP backend
2. Using REST/JSON API with gRPC backend
3. Using REST/Proto API with gRPC backend
4. Using gRPC-Web API with gRPC backend

This will allow users to "dip their toes" in protobuf without actually having to rewrite all of the clientside code to use gRPC clients from the get-go.

Bidirectional streaming should also be supported using newline-delimited messages when using the text-based application/json and application/x-protobuf+text content types, since this might soon become a very real thing even with simple fetch streams (https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams).

Fully implementing this will pretty much mean that WebSocket/EventStream implementations for simple transcoding will be easy to write using all the marshaling/proxying mechanisms implemented in this issue.

Now that v0.0.1 is released, use it in gotestapi to have a public example of how grpcbridge can already be used as an embedded alternative to gRPC-Gateway.

To be able to easily use grpcbridge as a library, the various components should be combined into a few root-level ones which perform all the necessary configuration behind the scenes and provide a more simple interface:

• ReflectionRouter, which should be constructible for both remote and local (embedded via bufconn or as a grpc ServerRegistrar) use-cases
• GRPCProxy which allows setting up a simple gRPC proxying component
• WebBridge which allows settings up a single bridging server supporting all the various webbridge components

A separate proxy component needs to be implemented to simplify interprocess communication via gRPC, allowing other grpcbridge components to use wrapped connections with additionally configured middleware, timeouts, connection management, etc. Without this component, the other components need complex management of shared instances of gRPC connections, which can really be simplified.

To test grpcbridge during initial development, develop a simple service in Go implementing a couple of gRPC endpoints. This seems easier than writing unit tests from the get-go considering the codebase will be changing quite a lot. The service should be dockerized with a compose file for easier local setup.