graphql-relay-php
graphql-query-complexity
| graphql-relay-php | graphql-query-complexity | |
|---|---|---|
| 1 | 4 | |
| 271 | 681 | |
| - | 0.1% | |
| 2.8 | 0.0 | |
| 7 months ago | 7 months ago | |
| PHP | TypeScript | |
| BSD 3-clause "New" or "Revised" 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-relay-php
-
To GraphQL or not to GraphQL? Pros and Cons
I have ported a library to create Relay compatible GraphQL APIs from JavaScript to PHP
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.
What are some alternatives?
starter-nextjs-blog - NextJS + Slicknode Headless GraphQL CMS blog starter kit
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.
foundation - GraphQL Foundation Charter and Legal Documents
crystal - 🔮 Graphile's Crystal Monorepo; home to Grafast, PostGraphile, pg-introspection, pg-sql2 and much more!
graphql-no-batched-queries - Graphql validation to disable batched queries and mutations.
analysis-ui - Front-end for Conveyal Analysis. Model and analyze transport scenarios.
falcor - A JavaScript library for efficient data fetching
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.
graphql-armor - 🛡️ The missing GraphQL security security layer for Apollo GraphQL and Yoga / Envelop servers 🛡️