-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get the serviceName in Service discovery #1183
Comments
I suspect the correct way of resolving this is to generate some As a workaround for the meantime you can create a no-op client to get the service name by creating something which conforms to struct NoOpChannel: GRPCChannel {
func makeCall<Request: SwiftProtobuf.Message, Response: SwiftProtobuf.Message>(
path: String,
type: GRPCCallType,
callOptions: CallOptions,
interceptors: [ClientInterceptor<Request, Response>]
) -> Call<Request, Response> {
fatalError()
}
func makeCall<Request: GRPCPayload, Response: GRPCPayload>(
path: String,
type: GRPCCallType,
callOptions: CallOptions,
interceptors: [ClientInterceptor<Request, Response>]
) -> Call<Request, Response> {
fatalError()
}
func close() -> EventLoopFuture<Void> {
fatalError()
}
} Then you can extract the service name for service discovery: let noOpGreeter = Helloworld_GreeterClient(channel: NoOpChannel())
let serviceName = noOpGreeter.serviceName I appreciate that it's not the nicest solution but it should at least unblock you! |
@glbrntt thanks your response so fast, what do you think if we change the |
Unfortunately we can't just make it We'd most likely want to generate some static service metadata alongside the protocol and then add a static property with a default implementation to the generated protocol, something like: protocol Echo_EchoClientProtocol: GRPCClient {
// existing
var serviceName: String { get }
// ...
// RPC definitions
// ...
// new:
static var metadata: GRPCServiceMetadata { get }
}
extension Echo_EchoClientProtocol {
// new, default impl.
static let metadata = GRPCServiceMetadata(name: "echo.Echo")
} |
@glbrntt couldn't we just add a static one? |
agree with you we can't break the api. I also have another question, I don't find the
|
We could, but it might just be more useful to have a more complete set of metadata (i.e. include RPCs as well). |
It doesn't exist yet! It could look something like that, it could also include other info like RPC metadata (i.e. name, request type, response type, whether the RPC streams requests or responses etc.). I'm just thinking out loud at this point though. |
Motivation: Sometimes it's useful to know information about a service, including its name, methods it offers and so on. An example where this is useful is service discovery (grpc#1183). However, we currently only provide the service name and this isn't available statically. For service discovery this is problematic as it requires users to create a client in order to get the service name so that a server can be dialled. For the async/await code, since it is not yet final, we can add requirements to generated protocols to provide the service metadata statically. Modifications: - Add service and method descriptors to `GRPC` - Generate service descriptors for client and server separately (it's feasible that a user may generate client code into one module and server code into separate modules) - Update the generated code for async/await and NIO based APIs to use the descriptors directly rather than generating literals in places where they are required. - Add test for the generated echo service metadata - Regenerate other services Result: Adopters can get static information about services.
Motivation: Sometimes it's useful to know information about a service, including its name, methods it offers and so on. An example where this is useful is service discovery (#1183). However, we currently only provide the service name and this isn't available statically. For service discovery this is problematic as it requires users to create a client in order to get the service name so that a server can be dialled. For the async/await code, since it is not yet final, we can add requirements to generated protocols to provide the service metadata statically. Modifications: - Add service and method descriptors to `GRPC` - Generate service descriptors for client and server separately (it's feasible that a user may generate client code into one module and server code into separate modules) - Update the generated code for async/await and NIO based APIs to use the descriptors directly rather than generating literals in places where they are required. - Add test for the generated echo service metadata - Regenerate other services Result: Adopters can get static information about services.
The 1.8.0 release adds support for this. See grpc-swift/Sources/Examples/Echo/Model/echo.grpc.swift Lines 387 to 424 in 703d351
|
What are you trying to achieve?
When I am creating the client, I want to use service discovery to get the service name. But I need to create
Client
then I can get the service name, if I want to createClient
I need to use host/port to create a channel, at here I need to use service name to get host. it become a cycle. could you give a suggestion?The text was updated successfully, but these errors were encountered: