4 ms·

I don't really understand it either. I thought the whole purpose of having an application layer on top of your database was to provide a specialized interface f

I don't really understand it either. I thought the whole purpose of having an application layer on top of your database was to provide a specialized interface for your application. If you're just going to provide a general query language to the frontend what is the point of the application layer? It seems like you'll just end up writing a database on top of your database. If you are writing a general purpose interface now, why are you writing custom code? Couldn't it all be abstracted out into an RDBMS? Would an RDBMS with user login and permissions system meant to be accessed by the end user/frontend be better than everyone writing their own weird database wrapper? It all seems very strange to me.

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 ago
  In 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 ago
    For 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 ago
    To 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.

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 ago
In 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 ago
  For 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 ago
  To 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.