Skip to content
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 scaffolding for client interceptors #986

Merged

Conversation

glbrntt
Copy link
Collaborator

@glbrntt glbrntt commented Oct 9, 2020

Motivation:

To support client interceptors we first need to define a few types to
work with.

Modifications:

  • Add client request and response parts.
  • Add the client interceptor protocol.
  • Add the client interceptor context, which is passed to functions on
    the interceptor protocol in order to allow implementations to invoke
    functions on interceptors either side of it in the pipeline.
  • Add a stubbed out client interceptor pipeline.

Result:

We have some base types for client side interceptors.

@glbrntt glbrntt requested a review from Lukasa October 9, 2020 13:31
@glbrntt glbrntt added the 🆕 semver/minor Adds new public API. label Oct 9, 2020
Sources/GRPC/Array+BoundsCheck.swift Outdated Show resolved Hide resolved
/// Forwards the response part to the next inbound interceptor in the pipeline, if there is one.
///
/// - Parameter part: The response part to forward.
/// - Note: This does *not* have to be called from the `EventLoop`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that worthwhile? NIO doesn't bother with this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I figured it'd be better to avoid failure since this could be called from off of the event loop, e.g. after deferring to e.g. UI for authentication or something. Perhaps it'd be better to document that it must be called from the event loop and keep the relevant assertions. WDYT?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think that that's probably better? It's a pretty significant perf win to avoid the check.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gave the pipeline the same treatment: it'll be internal and the inbound side will already be on the event loop. The outbound side will be invoked from the call object, so we can push the check there instead.

Sources/GRPC/Interceptor/ClientInterceptorContext.swift Outdated Show resolved Hide resolved
if let outbound = self.nextOutbound {
outbound.invokeWrite(part, promise: promise)
} else {
promise?.fail(GRPCStatus(code: .unavailable, message: "The RPC has already completed"))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this right? There seems to be some inconsistency between _read and _write that I don't fully understand about when the next interceptor might be nil.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So _read is more like NIOs fireChannelRead rather than NIOs read.

What's not implemented here is removing the contexts when the RPC completes, that's when we expect them to be nil.

Sources/GRPC/Interceptor/ClientInterceptorPipeline.swift Outdated Show resolved Hide resolved
Sources/GRPC/Interceptor/ClientInterceptorPipeline.swift Outdated Show resolved Hide resolved
Sources/GRPC/Interceptor/ClientParts.swift Outdated Show resolved Hide resolved
Motivation:

To support client interceptors we first need to define a few types to
work with.

Modifications:

- Add client request and response parts.
- Add the client interceptor protocol.
- Add the client interceptor context, which is passed to functions on
  the interceptor protocol in order to allow implementations to invoke
  functions on interceptors either side of it in the pipeline.
- Add a stubbed out client interceptor pipeline.

Result:

We have some base types for client side interceptors.
@glbrntt glbrntt force-pushed the gb-feature-interceptors-01 branch from 5f81f87 to 3ea34a1 Compare October 12, 2020 14:12
@glbrntt glbrntt merged commit ad486c8 into grpc:gb-feature-interceptors Oct 13, 2020
@glbrntt glbrntt deleted the gb-feature-interceptors-01 branch October 13, 2020 08:52
glbrntt added a commit that referenced this pull request Oct 29, 2020
Motivation:

To support client interceptors we first need to define a few types to
work with.

Modifications:

- Add client request and response parts.
- Add the client interceptor protocol.
- Add the client interceptor context, which is passed to functions on
  the interceptor protocol in order to allow implementations to invoke
  functions on interceptors either side of it in the pipeline.
- Add a stubbed out client interceptor pipeline.

Result:

We have some base types for client side interceptors.
glbrntt added a commit that referenced this pull request Nov 6, 2020
Motivation:

To support client interceptors we first need to define a few types to
work with.

Modifications:

- Add client request and response parts.
- Add the client interceptor protocol.
- Add the client interceptor context, which is passed to functions on
  the interceptor protocol in order to allow implementations to invoke
  functions on interceptors either side of it in the pipeline.
- Add a stubbed out client interceptor pipeline.

Result:

We have some base types for client side interceptors.
glbrntt added a commit that referenced this pull request Nov 12, 2020
Motivation:

To support client interceptors we first need to define a few types to
work with.

Modifications:

- Add client request and response parts.
- Add the client interceptor protocol.
- Add the client interceptor context, which is passed to functions on
  the interceptor protocol in order to allow implementations to invoke
  functions on interceptors either side of it in the pipeline.
- Add a stubbed out client interceptor pipeline.

Result:

We have some base types for client side interceptors.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🆕 semver/minor Adds new public API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants