> 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. On Wednesday, September 7, 2022 at 7:51:59 AM UTC-7 Remek Zajac wrote: > 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. > > > On Friday, November 4, 2016 at 9:01:38 PM UTC+1 Mark Nuttall-Smith wrote: > >> Ok, thanks for the confirmation. I'll do the routing via subdomains. >> >> Regards, >> Mark >> >> >> On Friday, 4 November 2016 16:48:03 UTC+1, Craig Tiller wrote: >>> >>> It's not possible, and not something we're currently planning. >>> >>> On Fri, Nov 4, 2016 at 5:18 AM Mark NS <[email protected]> wrote: >>> >>>> 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... >>>> >>>> >>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> 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 >>>> >>>> <https://groups.google.com/d/msgid/grpc-io/0190b636-3e69-4299-944b-d4a292df26ad%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/6f13f77b-9b26-45a0-bee4-cac5e8872889n%40googlegroups.com.
