Open d1820 opened 2 years ago
Yeah, that's a pretty non-standard situation. Even in the doc you linked:
The address path is ignored because gRPC has a standardized, prescriptive address structure. A gRPC address combines the package, service and method names:
https://localhost:5001/PackageName.ServiceName/MethodName
.
Bummer. So what is the prescribed way of hosting in production? Dedicated subdomains?
@lucasmaj that is the direction we ended up taking.. we rolled back all our . net code for sub directories and switched to domains
Bummer. So what is the prescribed way of hosting in production? Dedicated subdomains?
@lucasmaj, @d1820, do you mean for backend routing, like through a reverse proxy? If so, you could configure different backend routes based on the service names -- so still using paths, just not custom path prefixes.
@lucasmaj, @d1820, do you mean for backend routing, like through a reverse proxy? If so, you could configure different backend routes based on the service names -- so still using paths, just not custom path prefixes.
That is exactly what I just figured out. Effectively, ingress routes based on gRPC service package name. I am going with this approach while I am waiting for subdomains/dns entries.
Seems GrpCurl is missing support for being able to add a sub directory for the request call.
Tried
Maybe i am not doing it correctly but nothing here seems to work
option 1
option 2
option 3
option 1
Any help or in site to this being a bug would be great.
Background in our .net core application to get it all working correctly we inject a custom httpHandler that appends the subdirectory to the outgoing request to the GRPC service. This all works and is actually presented as the way by Microsoft: https://docs.microsoft.com/en-us/aspnet/core/grpc/troubleshoot?view=aspnetcore-6.0#calling-grpc-services-hosted-in-a-sub-directory