GRPC name resolution problem

[ey-in-vorontsov]

Hello,

When trying to access GRPC that isn't located in root (/) context it fails with error:

{
  "code": 14,
  "details": "Name resolution failed for target dns:host/ws",
  "metadata": {}
}

I'm trying to access method in /ws context. For example:

GRPC HOST/ws/com.some.pkg....

It resolves everyting until /com as host.

[AnWeber]

The reason is probably that grpc-js does not work as expected. To the ServiceClientConstructor, the complete url host/ws is passed. I assumed that the address also allowed subpaths. I search once in the documentation how and if it works correctly.

[AnWeber]

@grpc/grpc-js is the successor of grpc. For grpc there is grpc/grpc#14900, which mentions prefix of url.
grpc/grpc#14900 (comment):

The host used to create the channel does not go into the path used by gRPC (the channel builder arg should not include the "/foo" portion from your example). Instead, HTTP/2 paths are specified in a :path header field, and gRPC clients generate these from the proto service definition in the form protoPackage.serviceName.methodName (see here).

I also found the following issue: grpc/grpc-node#980 (comment). grpc-js does not seem to support this feature.

I will extend httpyac so that the options can be set from outside (support channelFactoryOverride). And in addition, I will interpret the specification of the Path instead of to the server to the service

[ey-in-vorontsov]

Ok, thank you very much! Please, make sure that this override will support variables from env (coz for local run there are no need in /foo, but for dev/qa/prod stand it is).

[AnWeber]

@ey-in-vorontsov May I ask what client you are using to support subpath in prod. Does it also support the specification of a path? In my search, I actually found that this usage is rather unsupported.
And I try to support the specification of a path. But I will not use an internal api. I don't have the use case myself and can't test this sufficiently and only with difficulty. A longer support would be very costly.

[ey-in-vorontsov]

We have standalone java application with REST API (/api) for external integrations and GRPC (/ws) for grpc-web. Url's are routed by nginx to same application with different ports.

On JS client side is generated code from proto that is used with API url:

new AuthServicePromiseClient(config.apiUrl); // Where config.apiUrl == http://host:port/ws

AuthServicePromiseClient:

export class AuthServicePromiseClient {
  constructor (hostname: string,
               credentials?: null | { [index: string]: string; },
               options?: null | { [index: string]: any; });

  auth(
    request: b$pn$proto$central_auth_auth_service_pb.AuthRequest,
    metadata?: grpcWeb.Metadata
  ): Promise<b$pn$proto$central_auth_auth_service_pb.AuthResponse>;

}

AuthServiceClient.auth:

proto.com.somespace.auth.AuthServiceClient.prototype.auth =
    function(request, metadata, callback) {
  return this.client_.rpcCall(this.hostname_ +       
      '/com.somespace.auth.AuthService/Auth',
      request,
      metadata || {},
      methodDescriptor_AuthService_Auth,
      callback);
};

NOTE: rpcCall is a method from AbstractClientBase in grpc-web (https://github.com/grpc/grpc-web/blob/627e33718d5055e3cfb9c8318e81cf1b4045b189/javascript/net/grpc/web/abstractclientbase.js#L54)

[AnWeber]

I have now tried to rebuild the PathAwareChannel. Unfortunately I could not test it reasonably and therefore I am dependent on help. Please test once with the next version.
Additionally it is now possible to pass the ChannelOptions. These are set by request.options.

proto < ./hello.proto

{{
  request.options = {
    channelFactoryOverride: (address, credentials, options) => {
      ....
    }
 };
}}

GRPC grpcb.in:9000/ws/hello.HelloService/sayHello
{
  "greeting": "world"
}

[ey-in-vorontsov]

Hello,

Thank you, I've checked and it seems that it works well!

But want to mention for history, that If no port defined (in case if 80 port is default port):

GRPC grpcb.in/ws/hello.HelloService/sayHello
{
  "greeting": "world"
}

Error will be:

{
  "code": 14,
  "details": "No connection established",
  "metadata": {}
}

[AnWeber]

It seems that grpc-js uses as default port 443 (used in line 83)

Thanks for the feedback:-)