@dthyresson Some notes and finding love to get your eyes on.
graphql-armor comes with several plugins already included and enabled by default here is an itemized list below of what Redwood would get.
To configure each plugin, it appears that you can just pass the EnvelopArmor constructor to an object containing the configuration for one or more of the plug-ins inside of it.
EnvelopArmorPlugin({
costLimit: {
enabled: true,
maxCost: 100,
objectCost: 1,
scalarCost: 1,
depthCostFactor: 2,
ignoreIntrospection: true,
},
maxAliases: {
enabled: true,
n: 1,
},
maxDirectives: {
n: 10,
},
maxDepth: {
n: 4,
},
maxTokens: {
n: 250,
},
})
The first thing that jumped out at me is that the depth-limit plugin for graphql-armor doesn’t allow you to configure ignoring certain fields like the current depth-limit plugin allows. Not sure if that is of any concern.
You also noted the rate-limit plugin, but it doesn’t appear graphql-armor offer a rate-limit plugin by default, and it also appears to be an optional configuration that the developer can add it on their own.
One question I have is how we should allow configuration for each plugin. Should we have, each plug-in configuration passed separately like with do for other configurations, ie.
export const handler = createGraphQLHandler({
loggerConfig: { logger, options: { query: true } },
depthLimitOptions: ...,
costLimitOptions, ...,
maxDirectivesOptions: ...,
// ...
})
Doing so would make existing configurations for plugins like depth-limit backward compatible (except for ignoring not being possible anymore).
Or should we just nest all configurations under a single property? ie.
export const handler = createGraphQLHandler({
loggerConfig: { logger, options: { query: true } },
armorOptions: {
maxDirectives: {
n: 10,
},
maxDepth: {
n: 4,
},
maxTokens: {
n: 250,
},
},
// ...
})
Doing this could allow for easier compatibility with future versions of graphql-armor since we’re just passing a big configuration object and don’t have to worry about updating or removing properties.
