search

Escape-Technologies / graphql-armor

🛡️ The missing GraphQL security security layer for Apollo GraphQL and Yoga / Envelop servers 🛡️
https://escape.tech/graphql-armor/docs/getting-started
MIT License
494 stars 28 forks source link

cost complexity changes for same document #665

Closed benasher44 closed 3 months ago

benasher44 commented 4 months ago

We're seeing some behavior that's unexpected wherein the calculated cost complexity changes across calls for the same hard-coded graphql document. My understanding was that graphql document validation doesn't incorporate variables, but maybe I'm misunderstanding? Anything else we should be aware of that we're missing?

We're using Apollo Server

nullswan commented 4 months ago

Indeed, variables are not computed.

It sounds like there's an issue. Could you provide a reproduction example? That would help us understand and resolve it faster. Thanks!

benasher44 commented 4 months ago

As soon as I can come up with one myself, I will. In a test environment, everything works as expected. So either apollo client or apollo server must be doing something.

benasher44 commented 4 months ago

But anyway, thanks for confirming variables are not considered, so it must be something else.

nullswan commented 4 months ago

Thanks, I have two more questions in mind.

Do you utilize a caching feature? What is the range of the variation?

benasher44 commented 4 months ago

The range is 6992 to 7060 in production. In tests, the query shows a cost of 5779 consistently.

For caching, we don't use persisted queries, but I believe Apollo Server has a validation cache, which would be in play here (not disabled).

benasher44 commented 3 months ago

Okay so not sure about the variability, but we did find that apollo-client adds the __typename field to all objects, which increases the complexity. Now, we can get the max complexity accurately, but we're not sure why sometimes it's lower in production.

nullswan commented 3 months ago

The range is 6992 to 7060 in production. In tests, the query shows a cost of 5779 consistently.

For caching, we don't use persisted queries, but I believe Apollo Server has a validation cache, which would be in play here (not disabled).

Yes it does: https://www.apollographql.com/docs/react/data/document-transforms/#document-caching

Okay so not sure about the variability, but we did find that apollo-client adds the __typename field to all objects, which increases the complexity. Now, we can get the max complexity accurately, but we're not sure why sometimes it's lower in production.

https://www.apollographql.com/docs/react/data/document-transforms/#interacting-with-built-in-transforms

Let me know if we can be any more helpful here :)

benasher44 commented 3 months ago

We're on apollo/client 3.6.2, so __typename is the only transform. I think it's safe to close this — not an issue with graphql-armor.