There's an interesting tension here. On one hand, GraphQL is versatile and can simplify frontend data handling code. On the other, as schema and data sizes grow

There's an interesting tension here. On one hand, GraphQL is versatile and can simplify frontend data handling code. On the other, as schema and data sizes grow, query expressiveness is limited and performance can be quite difficult to maintain. I've put GraphQL in front of TB-scale data sources with X00,000 tables, and it was clear that (a) GraphQL wasn't designed for anything that big, and (b) if we could get it there, it would be transformational. This is why I built Trustfall[0]: a system that keeps the elegant GraphQL syntax, and tweaks the semantics to ensure great performance and better expressiveness: left joins / recursion / aggregations / arbitrary filters etc. Trustfall flips the proposition around: acknowledge we're wrapping a database around every data source (API server / database / filesystem / ML etc.) and make it the best possible database it could be. I gave a talk on it titled "How to Query (Almost) Everything" at the HYTRADBOI'22 conference: https://www.hytradboi.com/2022/how-to-query-almost-everything https://www.hytradboi.com/2022/how-to-query-almost-everythin... I also recently used it to build cargo-semver-checks[1], a semver linter for Rust crates where each semver rule is implemented as a query using Trustfall's GraphQL + custom directives syntax. [0]: https://github.com/obi1kenobi/trustfall https://github.com/obi1kenobi/trustfall [1]: https://crates.io/crates/cargo-semver-checks https://crates.io/crates/cargo-semver-checks