Policy Instance Lifecycle in the Policy Engine #395
renuka-fernando
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Policy Instance Lifecycle in the Policy Engine
Motivation
The gateway v0.0.1 keeps a single policy instance of a policy globally for all the routes. But there is a requirement where some policies need preprocessing initParameters and parameters (user parameters) and cache them in the policy instance. In such cases, a single global instance is not sufficient. If policy engine supports creating multiple instances of a policy, then each route can have its own instance of the policy with its own cached data.
Solution
Policy implementation should have a func named
NewPolicywhich returns an instance of the policy. Policy Engine will pass:metadata- Contains route-level metadata (currently just routeName)initParams- Static policy configuration from policy definitionparams- Dynamic user parameters from API configurationPolicy implementation can use these to create multiple instances if required or return a singleton instance if multiple instances are not required. This enables having a policy instance per route or per initParams/params combination. The instancing strategy is decided by the policy implementation itself.
Signature:
All initialization, validation, and preprocessing should be done in
NewPolicy. The function returns an error if initialization fails.Examples
Example 1: Singleton Pattern (Stateless Policy)
Policies with no cacheable state can use a singleton. Basic-auth is a good example - all configuration comes via params on each request.
Example 2: Cached Multi-Instance Pattern (Shared Config)
Policies that need to preprocess/cache configuration can reuse instances across routes with identical config. JWT validation is ideal - parsing public keys is expensive.
Example 3: Per-Route Instance Pattern (Route-Specific State)
Policies that maintain route-specific state need dedicated instances per route. Rate limiting is a perfect example - each route needs its own counters.
Key insight: Cache by
routeNameto ensure one instance per route and preserve state across config reloads.Summary
Three caching strategies for policy instances:
initParamshashrouteNameBeta Was this translation helpful? Give feedback.
All reactions