https://hackerpaper.kaipfister.de/p/2009.05632/Collected HN comments and submissions linking this paper.enMon, 02 Nov 2026 11:16:22 GMThttps://news.ycombinator.com/item?id=34515986urn:hackerpapers:mention:2009.05632:34515986Wed, 25 Jan 2023 08:51:18 GMT<p>Cool stuff, congrats on the launch! I am excited to learn about the details for complexity-based rate limits, as there are quite a few design considerations involved. For example, how to configure which (numeric) arguments in a GraphQL query actually impact complexity. The example in the blogpost relies on `first`, which seems to be derived from Relay Connections. But implementations might differ and user other arguments. We did research in this area (cf. https://arxiv.org/pdf/2009.05632.pdf) and proposed a specification to embed required configuration in the GraphQL schema (cf.…</p><p><a href="https://hackerpaper.kaipfister.de/p/2009.05632/">Paper and discussion history</a>. A mention is not an endorsement.</p>cs.SEhttps://news.ycombinator.com/item?id=32374863urn:hackerpapers:mention:2009.05632:32374863Sun, 07 Aug 2022 08:25:17 GMT<p>We did research on solving the DOS issue using static analysis at IBM (cf. https://arxiv.org/pdf/2009.05632.pdf). Our findings were that static analysis allows to determine (relatively strict) upper bounds on query complexity, which we assessed for two production GraphQL APIs (GitHub and Yelp). However, the static analysis requires some configuration to determine the (maximum) size of lists. I was later involved in productising said research into an API gateway (called DataPower) offered by IBM. We implemented our GraphQL static analysis in a quite flexible and performant way (all of…</p><p><a href="https://hackerpaper.kaipfister.de/p/2009.05632/">Paper and discussion history</a>. A mention is not an endorsement.</p>cs.SE