graphql-query-complexity
graphql-no-batched-queries
graphql-query-complexity | graphql-no-batched-queries | |
---|---|---|
4 | 2 | |
681 | 5 | |
0.1% | - | |
0.0 | 2.5 | |
7 months ago | 26 days ago | |
TypeScript | TypeScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
graphql-query-complexity
-
Migrating Netflix to GraphQL Safely
https://github.com/slicknode/graphql-query-complexity
In addition you could introduce CI tools to enforce your devs stop writing such complex queries. Also see the @skip and @include directives that can further be used to control what data is queried. In practice, however, this isn't something that comes up too much. In cases where I have seen this happen, it's usually because a developer is trying to reuse fragments without considering what data they are querying, and whether they should be reusing those fragments.
https://graphql.org/learn/queries/#fragments
-
GraphQL DoS amount-attack "breadth"
very cool! I was looking at https://github.com/slicknode/graphql-query-complexity
-
Preventing GraphQL batching attacks
There are a couple of techniques that can be used to prevent this kind of problem one of them is GraphQL Query Complexity Analysis which is, as the name suggests, very complex to implement correctly. It requires analysis of how the graphql API is used, and what queries and mutations are most often called. If you get this wrong, there is a danger of the server denying perfectly valid queries.
-
To GraphQL or not to GraphQL? Pros and Cons
The problem is that those queries are not prevented by commonly available rate limiters. You can send a single request to a GraphQL server that completely overwhelms the servers. To prevent such queries to GraphQL APIs, I wrote graphql-query-complexity, an extensible open-source library that detects such queries and rejects pathological queries before consuming too many resources on the server. You can assign each field a complexity value, and queries that exceed a threshold will be rejected. In Slicknode this protection is added automatically based on the number of nodes that are being returned.
graphql-no-batched-queries
-
Preventing GraphQL batching attacks
I've also created another validation library: No batched queries, which limits the number of all queries and mutations that could be sent per request. It pairs nicely with this validation, so you could allow, for example, 3 queries to be sent and then use noAlias to disable duplicate queries.
So I've created two small libraries (graphql directives) for Node that will handle this kind of abuse easily (by validating incoming requests) The first graphql-no-batched-queries will limit the number of queries or mutations per request.
What are some alternatives?
dataloader - DataLoader is a generic utility to be used as part of your application's data fetching layer to provide a consistent API over various backends and reduce requests to those backends via batching and caching.
starter-nextjs-blog - NextJS + Slicknode Headless GraphQL CMS blog starter kit
graphql-no-alias - No alias directive for graphql mutation and query types. It can limit the amount of alias fields that can be used for queries and mutations, preventing batch attacks.
crystal - 🔮 Graphile's Crystal Monorepo; home to Grafast, PostGraphile, pg-introspection, pg-sql2 and much more!
analysis-ui - Front-end for Conveyal Analysis. Model and analyze transport scenarios.
falcor - A JavaScript library for efficient data fetching
foundation - GraphQL Foundation Charter and Legal Documents
graphql-armor - 🛡️ The missing GraphQL security security layer for Apollo GraphQL and Yoga / Envelop servers 🛡️