-
-
Notifications
You must be signed in to change notification settings - Fork 566
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
Interceptors Proposal #3614
Comments
I'm trying #3616. Is this possible? // Create interceptors
interceptors := &genservice.ServerInterceptors{
AuditInterceptor: AuditInterceptor,
RetryInterceptor: RetryInterceptor,
}
// Create endpoints with interceptors
endpoints := genservice.NewEndpoints(svc, interceptors) |
Good catch, that's not how interceptors ended up being implemented. Instead there is a single generated interface that exposes all the interceptors. The end user provides the implementation for this interface and Goa calls the right interceptors at the right time. I've added an example: https://github.com/goadesign/examples/tree/features/interceptors/interceptors. |
I'm working on adding streaming support for interceptors by adding |
Just to help with that: maybe you could create a branch in the goa.design/examples repo, add streaming endpoints to the interceptors example and write the code that should be generated. That way we can review what the output ought to be and the example can be used as a reference when working on the code generation. Also https://github.com/goadesign/goa/blob/v3/codegen/service/interceptors.md contains the details of how the current interceptors were implemented. |
Interceptors in Goa
Overview
This proposal introduces typed interceptors to Goa's design DSL. Interceptors provide a type-safe mechanism for injecting cross-cutting concerns into method execution, with clean interfaces for reading and modifying payloads and results. They can be defined at API, Service, and Method levels.
Requirements
Design
DSL Example
This proposal introduces the following new DSL:
Interceptor(name string, dsl func())
- Defines a new interceptor. Used at design package level to define interceptor types.ServerInterceptor
- Applies a server-side interceptor atAPI
,Service
orMethod
level.ClientInterceptor
- Applies a client-side interceptor atAPI
,Service
orMethod
level.ReadPayload(dsl func())
- Defines the payload attributes that the interceptor needs to read. Used within Interceptor DSL.WritePayload(dsl func())
- Defines the payload attributes that the interceptor will modify. Used within Interceptor DSL.ReadResult(dsl func())
- Defines the result attributes that the interceptor needs to read. Used within Interceptor DSL.WriteResult(dsl func())
- Defines the result attributes that the interceptor will modify. Used within Interceptor DSL.Implementation Example
The user code implements the interceptors as follows:
The generated interceptor info object provides access to the service and method names as well as the current payload. It also exposes methods to retrieve the payload and result context objects which allow for type-safe access and modification.
There is also a new type defining the signature for the next function that is common to all interceptors:
Client-side interceptors are also supported. They follow the same pattern as server-side interceptors. In this example
RetryInterceptor
does not need to read or modify the payload or result.Generated Interceptor Code
A new
interceptors.go
file is generated undergen/<name of service>/interceptors.go
with the following content:Generated Service Code
Additionally the generated
endpoints.go
file is modified to call the interceptors:Generated Client Code
The generated service package
client.go
is updated to hook up the client side interceptors as follows:Key Features
Type-Safe Access
Clean Modification Pattern
Flexible Chain Control
Design Integration
/cc @tchssk @ElectricCookie
The text was updated successfully, but these errors were encountered: