Customizing gRPC URLs?

[JamesNK]

How strict is the gRPC standard with respect to URLs?

Today we generate URLs that always place them at the root of the web app.

e.g. /Count.Counter/AccumulateCount

Is there flexibility to have them prefixed with a URL segment in a web app?

e.g. /api/Count.Counter/AccumulateCount

If this is allowed then we should provide a way to customize service URLs in the startup experience.

---

UPDATE 2021/04/21 ✔️

Calling a service in a sub-directory documented here: https://docs.microsoft.com/en-us/aspnet/core/grpc/troubleshoot#calling-grpc-services-hosted-in-a-sub-directory

[dhhoang]

The way I understand it, URL prefixes don't work well with generated clients (see grpc/grpc/issues/14900).

[JamesNK]

https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md

Some gRPC implementations may allow the Path format shown above to be overridden, but this functionality is strongly discouraged. gRPC does not go out of its way to break users that are using this kind of override, but we do not actively support it, and some functionality (e.g., service config support) will not work when the path is not of the form shown above.

[dhhoang]

Question related to #43
Will the managed client be generated as well (based on .proto file)? There doesn't seem to be a way to specify a custom url prefix in the .proto file .

[JamesNK]

I could be configuration in the client. You'll already need to specify a base address. A prefix could be part of that, e.g. https://localhost:1111/prefix

[dhhoang]

Right, but other generated clients might not work well with it.
Let's say I have some .proto files and and build a Aspnet core server, and then generate my C#/Ruby/Java client with the Grpc core tool. As per grpc/grpc#14900 (comment) the client would set the HTTP2 :path header based on the default format. The prefix wouldn't be compatible then.

[JamesNK]

We'll be writing a managed client at some point. If we want to support a prefix then we'd include it in request's :path

[kinglionsoft]

My grpc server is hosted by Service Fabric as a guest executable service. The accessing url of this service via the reverse proxy from outside the cluster becomes:

http://servicefabric:19081/GuestExeSample/GrpcHello

In order to using current grpc client to access this service, I have to transfer the url to another port without path through nginx.

server {
    listen 9001 http2;
    location / {
         grpc_pass grpc://servicefabric:19081/GuestExeSample/GrpcHello;
    }
}	

It's a good idea that a managed client supports a prefix. @JamesNK

[ysaakpr]

I think this should be considered as a core feature on the Grpc library. Day by day many api gateways are supporting Grpc communication on top of them, so mounting the services on a custom path or on a virtual host is trivial. Support for the clients to use default path prefix would be an ideal feature to include in all the libraries built by the Grpc client. I prefer the prefix to be not part of proto file, rather it should be just a default path prefix in the clients.