Specification for cost calculation algorithm

[Laurin Quast]

It would be handy to have a specification of the cost calculation algorithm so it can easily be implemented in other languages or other tooling for auditing/analyzing existing GraphQL operations.

[Maxence Lecanu]

Hello !

We will use this issue to centralize discussions about query complexity and related rate-limiting.

Holidays went by but we discussed internally with @c3b5aw about this matter. Ideally, our course of action regarding query complexity assessment would have two parts:

1. Define the complexity evaluation method

We would like a consensual method for evaluating the complexity to be discussed and defined at the specification level. Only on this project, there are many influent folks involved in the discussion and we feel like it might be "bigger" than the maintainers of armor only to decide how query complexity should be evaluated.

This is even more important to us, as some tools intend to provide armor by default in the future.

Another major concern that we would like to tackle doing this, is that as far as I deeply agree with you @hayes about QC to be handled at the schema level, it involves that we work with the dynamic schema, and eventually its parser.

We already have to consider two engines in order to be relevant in armor, and this is a bit of a mess for us sometimes. The best thing that could happen to the ecosystem is to settle down on a standard, yet flexible method for this, thus thinking out of the parser.

2. Provide a reference implementation in a separate package, make armor compliant with it

GraphQL-Gate seems really nice for doing the limitation, but it involves that we start instrumenting the dynamic schema ourselves, which we would like not to do, ideally. Mostly, I am not sure that I want this instrumentation to be done magically under the radar by armor (and in this case by a third-party dependency).

On many aspects to me, complexity analysis appears like a different topic than pure security, and I am puzzled not handling it like it deserves.

I am keeping this issue opened and closing the other ones about complexity, so that we can talk this through in a single space :)

[Maxence Lecanu]

Note: our position on this matter is definitely not a steady one and should be expected to be both plastic and likely to evolve.

Note (1): Two papers that we could leverage moving forward.

• IBM that was mentioned in #90
• QC from shopify

[Maxence Lecanu]

Hello ! A quick update on where we stand, and what our first level of implementation will look like:

1. We decided to keep the query complexity as simple as possible over a first iteration.

Reasons:

• Armor aims at providing security defaults without configuration requirements.
• We are all intimately convinced in the team that every usages of this feature cannot be solved in a generalized way and evolved query complexity will, in fine, always require dedicated attention from the end user.
  Tools for that already exist: Graphql-gate is one, the plugin on Pothos is another one.
• In a nutshell, we feel like it will not be effective to provide yet another layer of complexity assessment

2. We will chose a default (shopify) presets to start with, and we will evaluate the query complexity using our plugin mechanics. We already have a basic plugin supporting this part in fact.

3. We will incorporate this in a rate limiter

4. Once this low-key feature is achieved, we will work on having the rate-limiter configurable enough so that one can use a custom complexity evaluation

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.