
A New Approach to GraphQL API Management - allthingsapi
https://www.ibm.com/blogs/research/2019/02/graphql-api-management/
======
krsyoung
Very cool. We're facing this common problem where endpoint consumers go query-
happy with GraphQL seeing as it is so easy to pull a large amount of data (or
trigger a large number of operations).

It is currently very unclear how much load is being caused by the
"convenience" of data-based queries. Having the ability to articulate and
limit these expensive operations via policy would be incredibly helpful in not
only shaping internal behaviour but also in exposing services to broader
audiences.

Curious what others in the community have done to hack something similar in
place?

~~~
ewittern
There are a few libraries that calculate complexity or cost of a GraphQL
query, e.g., [1][2]. We think that differences of our approach are that we
extract more diverse characteristics, allowing for a wider array of management
policies, and that we explicitly decouple management from the backend
implementation. In consequence, our approach works irrespective of the
programming language used for the GraphQL backend, prevents malicious requests
from even hitting the backend, reduces backend load, and lifts developers from
having to integrate cost / complexity calculations themselves.

[1] [https://github.com/pa-bru/graphql-cost-analysis](https://github.com/pa-
bru/graphql-cost-analysis) [2] [https://github.com/slicknode/graphql-query-
complexity](https://github.com/slicknode/graphql-query-complexity)

