Extensions: Context structure and getter / setters

[o0Ignition0o]

This discussion will hopefully allow us to iterate on the various tradeoffs to be made, while we're designing a Context and Extensions.

Let's share the requirements we have here, and have this discussion lead to an ADR.

I have written a strawdog proposal for a context_ext model that can be found here:

https://github.com/o0Ignition0o/context_ext_strawdog/blob/main/src/main.rs

This is of course a very rough draft, but I believe it outlines how i envisioned getters / setters and the ability for Rust and non rust languages to interop with it

[o0Ignition0o]

My main concern is that the context should IMO be shareable across each plugin, and by that I mean I would even go as far as requiring any type within the context extensions to implement Serialize / Deserialize.

This wouldn't have an impact for Rust extensions / plugin builders, since they just wouldn't need to call serialize / deserialize functions, but it would force everyone to make their structures "interop ready" in a sense.

The main reason why I think this would make sense is because I believe we're building a rust router for everyone, and that means rustaceans, but also companies that aren't used to writing rust, and I want to make sure we always have them in mind when building extensibility and extensions.

Rust plugins would probably be faster, and we would skip a Serialize / Deserialize step which would be better perfomance wise, but it would still allow people to write their own plugins and "get things done".

[BrynCooke]

I'd like to know the use case for context sharing across plugins. Plugins should generally not be aware of each other, so should not need to communicate. If we can think of good use cases though then that's another matter.

[Geal]

Those example are super interesting. Maybe we try and implement something along the lines of the envoy plugin?

we can implement something, but we should not make it available so soon, I'd like us to explore in depth what we need on authenticationand authorization first, because we have more complex use cases than HTTP reverse proxys

[Geal]

honestly I am a bit worried that making one plugin appear at multiple hook points will be hard to integrate in the router (except maybe if the entire state of the plugin is stored in the context)

[Geal]

It would mean that a WASM plugin would not be able to take advantage of any JWT processing done in a JWT plugin, but I see this as a good thing.

That would result in plugins covering more and more feature space, instead of doing one small thing. Example: the JWT plugin verifies the signature, checks revocation, extract claims. Does it also handle authorization at the entire request level? Does it embed authorization policies at the field level? If we have per subgraph policies we also need that JWT plugin to be called at subgraph request time.
While when we have plugins communicate with each other, we get:

• JWT plugin verifies the signature, checks revocation, extract claims, stores claims and JWT in context
• authorization plugin looks at claims to accept or not the request. When the response comes back, it filters fields according to policies depending on the claims
• subgraph auth plugin can accept or redirect a query depending on the claims, and replace the JWT with another one

If plugins can share info through the context, every one of those steps can be replaced (ex: making a different authz plugin based on OPA or Casbin) without having to rewrite the entire chain

[BrynCooke]

I see your point. Cross plugin communication seems desirable.

[o0Ignition0o]

Now that’s a super nice use case to focus on, thanks for sharing!