-
Notifications
You must be signed in to change notification settings - Fork 435
Add Client object #1729
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
Add Client object #1729
Conversation
|
This builds on top of and supersedes #1727 |
| /// In contrast to ``RPCError``, the ``ClientError`` represents errors which happen at a scope | ||
| /// wider than an individual RPC. For example, attempting to start a client which is already | ||
| /// stopped would result in a ``ClientError``. | ||
| public struct ClientError: Error, Hashable, @unchecked Sendable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: Should we name this GRPCClientError if the type is called GRPCClient?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this can be thrown by any client side code, not necessarily the GRPCClient. There are a few places where I'd like to reuse this (one example being an interceptor throwing an error)
| private let transport: any ClientTransport | ||
|
|
||
| /// The configuration used by the client. | ||
| public let configuration: Configuration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to make this public. Users cannot change anything anymore on it. Do you have a use-case in mind where people might want to access this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Visibility, i.e. being able to see what the configuration is.
| /// | ||
| /// - Parameters: | ||
| /// - descriptor: The ``MethodDescriptor`` for which to get or set a ``MethodConfiguration``. | ||
| public subscript(_ descriptor: MethodDescriptor) -> MethodConfiguration? { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to subscript for a service in the future? Then I think making the subscript argument label external makes sense.
| public subscript(_ descriptor: MethodDescriptor) -> MethodConfiguration? { | |
| public subscript(descriptor: MethodDescriptor) -> MethodConfiguration? { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so.
If we did eventually want to add one then there's no harm in the service subscript having an external label and this one not having one.
Motivation:
Clients are the highest level API to make requests to a gRPC server.
Modifications:
Add a
GRPCClientResult:
We now have a high level client that can be used by the generated stubs to start RPCs to gRPC servers.