3 ms·

Can you explain the difference? I’ve written many RESTlike APIs (no hypermedia) and they mostly returned data. In fact, the whole premise is to be able to acc

by ulkesh 8y ago

Can you explain the difference? I’ve written many RESTlike APIs (no hypermedia) and they mostly returned data. In fact, the whole premise is to be able to access resources which typically boils down to some data model response.

lolive 8y ago
Disclaimer: I come from the Semantic Web area. Where the client language is SPARQL, and the (graph) database is exposed publicly and understands SPARQL. The data are exchanged in RDF (a kind of JSON for graph data). A SPARQL query can federate data from several SPARQL endpoints (this is all the point of the LinkedData movement). So we have NO additional layers between the DB and the client (except for some security features, and query throttling) This is a simple pattern that makes data access trivial. (if you manage to store your data in such a graph database, which is NOT trivial) As far as I understand, if you follow a similar philosophy, then GraphQL will shine too (especially because the tooling on the client-side is infinitely superior with GraphQL, than it is with SPARQL). But the more I read this HN thread, the more it seems GraphQL is used for service integration. And that is a completely different problem. So, I feel like data access with GraphQL is super nice. (especially if you use best practices for your data, like in the LinkedData principles) But service integration sounds yet another hell. (because services are rarely designed to be properly integrated together).
- ulkesh 8y ago
  I completely understand now where you’re coming from. Thing is, we’re taking an existing data model that has REST in front of it (a layer or two up), and trying to instead use GraphQL. I think, though anecdotal for me, that this is the more typical use case since most won’t be able to re-engineer the database to be more conducive to GraphQL. And I think this now makes some sense as to why there is hardly any documentation with respect to practical GraphQL and ORM (in the vein of Spring Boot and Hibernate for us old Java folk). Thanks for the explanation!

by ulkesh 8y ago

lolive 8y ago

Disclaimer: I come from the Semantic Web area. Where the client language is SPARQL, and the (graph) database is exposed publicly and understands SPARQL. The data are exchanged in RDF (a kind of JSON for graph data). A SPARQL query can federate data from several SPARQL endpoints (this is all the point of the LinkedData movement). So we have NO additional layers between the DB and the client (except for some security features, and query throttling) This is a simple pattern that makes data access trivial. (if you manage to store your data in such a graph database, which is NOT trivial) As far as I understand, if you follow a similar philosophy, then GraphQL will shine too (especially because the tooling on the client-side is infinitely superior with GraphQL, than it is with SPARQL). But the more I read this HN thread, the more it seems GraphQL is used for service integration. And that is a completely different problem. So, I feel like data access with GraphQL is super nice. (especially if you use best practices for your data, like in the LinkedData principles) But service integration sounds yet another hell. (because services are rarely designed to be properly integrated together).

ulkesh 8y ago
I completely understand now where you’re coming from. Thing is, we’re taking an existing data model that has REST in front of it (a layer or two up), and trying to instead use GraphQL. I think, though anecdotal for me, that this is the more typical use case since most won’t be able to re-engineer the database to be more conducive to GraphQL. And I think this now makes some sense as to why there is hardly any documentation with respect to practical GraphQL and ORM (in the vein of Spring Boot and Hibernate for us old Java folk). Thanks for the explanation!