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
process* 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
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).
a directory with a bunch of unix sockets, one per service.