[lstamour]

Theoretically, a smart enough GraphQL front-end could recognize multiple filters and do some or all of the filtering client-side, or if impossible, request both from the server. The idea that your client can declare what data it needs rather than leaving it up to the server is the best part of GraphQL, the thing that simplified it the most. But it’s hard to do well, right now. It’s much easier to use code-gen directly to have client and server share knowledge of what’s needed. HTTP2 push adds an interesting twist though, when your GraphQL response could actually trigger additional client code and resources to be sent. Of course this can be done without GraphQL, but you’d still need a server that’s aware of what data the client will use and how. For simple APIs or APIs with many clients that behave the same way, GraphQL is overkill. But even so it’s an interesting alternative to simple REST and simple state management, and unlike Redux, you can trigger multiple events at the same time which can be beneficial if processing their state changes at the same time would lead to a more efficient update. (The Redux alternative is to add some kind of wrapper event, or an event for each combination of events...)