You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today it is not very easy to customize pipelines in core-http as they are presented as a difficult-to-inspect array of policy factories. The new design seeks to:
Make it easy to compose pipelines by expressing dependencies between policies
Make it easy to remove policies that are unnecessary (so as to replace them with new custom policies)
Avoid unnecessary allocations after creating a policy, such that new isn't required to be called when executing a particular policy per operation.
Design
Policies
A PipelinePolicy is an object that implements the following interface:
It is given a string name (policies defined in core will use strings from an exported string enum) so that consumers can express dependencies relative to existing policies. The sendRequest method uses a middleware pattern, which is familiar to JS devs.
Open Question: Is there a way to type responses here for deserialization policies?
Pipelines
A Pipeline composes several policies and provides the ability to make a request that will flow through the policies in a specific order determined by their requirements.
Dependencies expressed when calling addPolicy are not sensitive to order. The following code snippets have identical effects:
pipeline.addPolicy(barPolicy);pipeline.addPolicy(fooPolicy,{afterPolicy: 'barPolicy'});// The below is the same as the above. // Policies don't have to be part of the pipeline in order to be // referenced by before/afterPolicy.pipeline.addPolicy(fooPolicy,{afterPolicy: 'barPolicy'});pipeline.addPolicy(barPolicy);
Phases are predefined buckets of activity that pre-defined policies inside core will fall into. They are currently a fixed set and not customizable by pipeline consumers.
Current proposed phases:
Serialize
Retry
Known phase names will be exported as a constant string enum.
Champion Scenarios
Inserting a new policy at a specific place
interfaceTracingPolicyOptions{tracingEnabled: boolean;}functiontracingPolicy(options: TracingPolicyOptions): PipelinePolicy{asyncfunctionsendRequest(request: Request,next: SendRequest): Promise<Response>{if(options.tracingEnabled){// add some headers or something!}returnnext(request);}return{name: "TracingPolicy",
sendRequest
}}// Extend an existing Pipelinepipeline.addPolicy(tracingPolicy({tracingEnabled: true}),{beforePhase: PipelinePhases.Retry});
Redesigning Pipelines
Goals
Today it is not very easy to customize pipelines in core-http as they are presented as a difficult-to-inspect array of policy factories. The new design seeks to:
new
isn't required to be called when executing a particular policy per operation.Design
Policies
A
PipelinePolicy
is an object that implements the following interface:It is given a string name (policies defined in core will use strings from an exported string enum) so that consumers can express dependencies relative to existing policies. The
sendRequest
method uses a middleware pattern, which is familiar to JS devs.Open Question: Is there a way to type responses here for deserialization policies?
Pipelines
A
Pipeline
composes several policies and provides the ability to make a request that will flow through the policies in a specific order determined by their requirements.Dependencies expressed when calling
addPolicy
are not sensitive to order. The following code snippets have identical effects:Phases are predefined buckets of activity that pre-defined policies inside core will fall into. They are currently a fixed set and not customizable by pipeline consumers.
Current proposed phases:
Known phase names will be exported as a constant string enum.
Champion Scenarios
Inserting a new policy at a specific place
Replacing retry policies
Other Considerations
The text was updated successfully, but these errors were encountered: