Add a 'UserInfo' heterotyped dictionary #1031
Conversation
|
cc @Davidde94 |
| * limitations under the License. | ||
| */ | ||
|
|
||
| internal final class Ref<Value> { |
There was a problem hiding this comment.
Extreme nit: If it's internal, does it really need to be final? (this doesn't change anything, just food for thought)
There was a problem hiding this comment.
I do this out of habit to be honest.
| /// Metadata to return at the end of the RPC. If this is required it should be updated before | ||
| /// the `responsePromise` or `statusPromise` is fulfilled. | ||
| public var trailers = HPACKHeaders() | ||
|
|
||
| public init(eventLoop: EventLoop, headers: HPACKHeaders, logger: Logger) { | ||
| public convenience init( |
There was a problem hiding this comment.
Do you think it's worth documenting behaviour re default UserInfo?
There was a problem hiding this comment.
Not really, to be honest. These context types are only public because they were created as public. They're not particularly useful by themselves.
A little more context: a subclass of this will be provided to the user provided method handler (i.e. the implementations of methods on their service), but of course the user isn't responsible for creating that context. Indeed the actual context provided is internal. The only time a user would want to create their own context would be to unit test their service provider in isolation, and we provide testing contexts just for that. I guess to sum up: documentation isn't useful because this API isn't really useful. And we're only keeping the API to not break existing users.
| @@ -31,12 +31,26 @@ open class StreamingResponseCallContext<ResponsePayload>: ServerCallContextBase | |||
|
|
|||
| public let statusPromise: EventLoopPromise<GRPCStatus> | |||
|
|
|||
| override public init(eventLoop: EventLoop, headers: HPACKHeaders, logger: Logger) { | |||
| public convenience init( | |||
There was a problem hiding this comment.
Same as above, up to you re documentation.
| @@ -35,12 +35,26 @@ open class UnaryResponseCallContext<ResponsePayload>: ServerCallContextBase, Sta | |||
| public let responsePromise: EventLoopPromise<ResponsePayload> | |||
| public var responseStatus: GRPCStatus = .ok | |||
|
|
|||
| override public init(eventLoop: EventLoop, headers: HPACKHeaders, logger: Logger) { | |||
| public convenience init( | |||
|
|
||
| public protocol UserInfoKey { | ||
| /// The type of `Value` identified by this key. | ||
| associatedtype Value |
There was a problem hiding this comment.
It seems strange to use Value to describe Value. You could just say "The type identified by this key".
Motivation: Interceptors may be used to provide additional information to the service provider. This could include information about an authenticated user, for example. However, we don't currently have such a mechanism. Modifications: - Add a type-safe 'UserInfo' dictionary - Add a 'UserInfo' requirement to the 'ServerCallContext' protocol - Store a 'Ref<UserInfo>' in the base call handler and pipeline, exposing the 'UserInfo' in both the server call context and server interceptor context. Result: Interceptors can share information in a type-safe way with the service provider.
glbrntt
force-pushed
the
gb-server-interceptors-heterotyped-dict
branch
from
a41246d to
94530ec
Compare
Motivation: Interceptors may be used to provide additional information to the service provider. This could include information about an authenticated user, for example. However, we don't currently have such a mechanism. Modifications: - Add a type-safe 'UserInfo' dictionary - Add a 'UserInfo' requirement to the 'ServerCallContext' protocol - Store a 'Ref<UserInfo>' in the base call handler and pipeline, exposing the 'UserInfo' in both the server call context and server interceptor context. Result: Interceptors can share information in a type-safe way with the service provider.
Motivation: Interceptors may be used to provide additional information to the service provider. This could include information about an authenticated user, for example. However, we don't currently have such a mechanism. Modifications: - Add a type-safe 'UserInfo' dictionary - Add a 'UserInfo' requirement to the 'ServerCallContext' protocol - Store a 'Ref<UserInfo>' in the base call handler and pipeline, exposing the 'UserInfo' in both the server call context and server interceptor context. Result: Interceptors can share information in a type-safe way with the service provider.
Motivation:
Interceptors may be used to provide additional information to the
service provider. This could include information about an authenticated
user, for example. However, we don't currently have such a mechanism.
Modifications:
exposing the 'UserInfo' in both the server call context and server
interceptor context.
Result:
Interceptors can share information in a type-safe way with the service
provider.