Proposal: Engine V1 REST API Transition


June 8


grpc allows multi-plexing multiple services into a single transport…
The aggregation is done automatically by grpc.

gRPC allows you to configure multiple “gRPC services” within the same
to a single transport. I think it’s important to mention that a
"gRPC service" is just a code construct. It’s not a “component”. This isn’t
much different from any REST API where you can configure multiple routes at
different urls on the same transport.

If you want to run different processes on the same transport you need
another proxy process which handles that multiplexing.

Does this match your understanding? Our working definition of "component"
has been “separate binary” (so a separate process). This means we would not
be running multiple components on the same socket/port. But a proxy can be
used to support that design.

Yes this does match my understanding. I think we have 2 viable options for

  1. a proxy as you describe. Note, we can develop a proxy that supports
    dynamic registration of components on a single address (ie all components
    connect to the proxy instead if the other way around).

  2. a directory with a bunch of unix sockets, one per service.


Option 1 is what I’ve been thinking and it would be part of the monolith to
make it easier to manage.



We are considering this approach in containerd and I think it is very viable. I think there is also the possibility to register services that are unknown at compile time, making the base of a very interesting plugin framework.