5 ms·
GQL makes it convenient for the front-end to assemble a collection of queries needed to render the page in a single request, and then go about its rendering bus
by WiseWeasel 7y ago
GQL makes it convenient for the front-end to assemble a collection of queries needed to render the page in a single request, and then go about its rendering business upon response. The React-Apollo client I use also features an in-memory cache that can serve as a state store, often entirely obviating the need for libs like redux.
- seanlaff 7y agoIn the reference implementations of GQL, that “one query” from the client balloons out in to possible hundreds of queries out the back side of GQL. Things like dataloader exist but the behavior of your schema gets harder and harder to reason about when different caching mechanisms get thrown on top. I think everyone agrees that the client facing api for GQL is fantastic... maybe that means graphdbs are the next wave :P
- tracker1 7y agoFor distributed data stores, with collectives of data across different databases/clusters it starts to make more sense. If you're using a column store structure for most data, you're mainly doing individual lookups based on a single key, graph data in another key/keys, and related keys looked up separately. Each optimized for the single record(s). Especially since distributed/collectively this data will be accessed faster than a single rdbms would be able to manage. That said, if your application can/does use a single sql datastore, and you don't need that much scale, the effort to setup/configure GQL may not be worth it in a given instance.
- WiseWeasel 7y agoTo me, on the back-end, GraphQL means replacing controllers with query (GET) and mutation (POST/PUT/DELETE) resolvers, with very similar concerns, routing takes place in the GQL schema, and everything else stays the same.