gRPC endpoint with non-root path

[Mark NS]

Maybe (hopefully) I'm missing something very simple, but I can't seem to figure this out.

I have a set of Python gRPC services that I would like to put behind a nghttpx proxy. For this I need to be able to configure my client with a channel on a non-root url. Eg.

channel = grpc.insecure_channel('localhost:50051/myapp')
stub = MyAppStub(channel)

This wasn't working immediately through the proxy (it just hangs), so I tested with a server on the sub context.

server = grpc.server(executor)
service_pb2.add_MyAppServicer_to_server(
    MyAppService(), server)
server.add_insecure_port('{}:{}/myapp'.format(hostname, port))
server.start()

I get the following

E1103 21:00:13.880474000 140735277326336 server_chttp2.c:159] 
{"created":"@1478203213.880457000","description":"OS Error",
"errno":8,"file":"src/core/lib/iomgr/resolve_address_posix.c",
"file_line":115,"os_error":"nodename nor servname provided, or not known",
"syscall":"getaddrinfo","target_address":"[::]:50051/myapp"}

So the question is - is it possible to create gRPC channels on non-root urls?

ps. Crossposted from http://stackoverflow.com/questions/40410392/grpc-endpoint-with-non-root-path - sorry, but I'm keen to find an answer for this...

[Craig Tiller]

It's not possible, and not something we're currently planning.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/0190b636-3e69-4299-944b-d4a292df26ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[MNS]

Ok, thanks for the confirmation. I'll do the routing via subdomains.

Regards,

Mark

[Remek Zajac]

Please forgive me for trying to resuscitate this dead horse, but I too am missing a point of de-referencing or am missing something conceptual 

and foundational. I assume gRPC as a technology and an interest group is keen on finding its way to backend applications and compete with REST.

A backend application often is a suite of microservices and if those expose gRPC services then there is a need to set up a proxy gateway that 

routes/forwards/muxes external calls to those services. 

And so a client sets up a channel to said proxy/gateway (host:port) and then attaches a client stub to it (package.ServiceName) and then

calls whatever rpcs it needs from that service. 

Now suppose the backend application implements two ImageTransform services - i.e.: services that can transform images given to them.

The rpc simply is image-in, image-out. We want to put two distinct implementations of the ImageTransform service definition and we want to 

give the client control over which one it wishes to access (the sharpening transform or the high-contrast transform). But the client has no 

means of specifying it and the server has no means of distinguishing two implementations of the same interface definition. I.e.: there seem

to be no finesse in the classic programming problem of distinguishing interface implementation from its definition. I am probably missing

a nuance, but I have read the core concepts https://grpc.io/docs/what-is-grpc/core-concepts and can't see anything obvious. Please advise.

[sanjay...@google.com]

> But the client has no  means of specifying it and the server has no means of distinguishing two implementations of the same interface definition

You can distinguish using one of (package.ServiceName) and that's available both on the client on server side. There are other ways as well e.g. use a different host name and route based on that.