A New Approach to GraphQL API Management

ibm.com

8 points·allthingsapi··3 comments

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?

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 [2] https://github.com/slicknode/graphql-query-complexity

Others have been looking at this problem and the possibilities of bringing down your backend with a mischievous request... https://blog.apollographql.com/securing-your-graphql-api-fro... reminds us of `select * from <big table>

Reply on news.ycombinator.com