4 ms·

Neatly coinciding with GraphQL's announcement 'Leaving technical preview' [1]. In hindsight, sending a query, written in a query language from client to server

by niftich 10y ago

Neatly coinciding with GraphQL's announcement 'Leaving technical preview' [1]. In hindsight, sending a query, written in a query language from client to server seems obvious. So obvious, that I think I've seen it before... select login, bio, location, isBountyHunter from viewer where user = ? It's ironic to me that it took Facebook reinventing SQL (or a graph database equivalent thereof [2][3][4]) and Github embracing it to legitimize this practice, since if you were doing this before, you were judged in the eyes of your peers and clients for not being "RESTful" (the fake-REST kind [5]), as if everyone was just itching to PUT and DELETE blobs of JSON of your poorly mapped resources to quasi-hardcoded, templated [6][7] URLs. What's old is new again, but this time I'll take it. [1] http://graphql.org/blog/production-ready/ http://graphql.org/blog/production-ready/ [2] https://neo4j.com/developer/cypher-query-language/#_about_cypher https://neo4j.com/developer/cypher-query-language/#_about_cy... [3] http://tinkerpop.apache.org/ http://tinkerpop.apache.org/ [4] https://www.w3.org/TR/sparql11-query/ https://www.w3.org/TR/sparql11-query/ [5] https://news.ycombinator.com/item?id=12479370#12480408 https://news.ycombinator.com/item?id=12479370#12480408 [6] http://swagger.io/specification/#pathTemplating http://swagger.io/specification/#pathTemplating [7] http://raml.org/developers/raml-200-tutorial#parameters http://raml.org/developers/raml-200-tutorial#parameters

gjtorikian 10y ago
> Neatly coinciding with GraphQL's announcement 'Leaving technical preview' We coordinated with Facebook to do that. ;)
rottyguy 10y ago
except they removed the physical knowledge and just went with logical associations
- halomru 10y ago
  SQL (at least the subset used for querying and modifying data) contains no physical knowledge either. In a SELECT-query a physical table and a logical view look and behave the same. If you only give your users access to views instead of physical tables you get the same result as GraphQL, just with different syntax.
  - deleted 10y ago
    [deleted]
skybrian 10y ago
The main thing is making it secure and scalable. The old client-server infrastructure for database apps was not designed to be deployed over the Internet.
- niftich 10y ago
  > secure and scalable > over the Internet What does this really mean? How does this substantially differ from the now-facetious term 'web scale' [1] ? Modern RDBMS'es offer encrypted communications between client and server [2][3][4], but nothing is stopping a deployer from putting a proxy between the database and the Internet-resident end-user to translate between authentication mechanisms. In fact, this happens in every single API today, where the Basic or OAuth or Cookie-Auth request comes in the HTTP body, and gets made into a database query in a query language the DB understands -- SQL or something else. GraphQL needs to you bring your own authn/z [5][6][7] much the same way that your run-of-the-mill HTTP API needs to you to bring your own authn/z, so I can't accept 'secure' as an innovation over SQL. "Scalable?" How? I genuinely think this tech is neat but let's consider what it gives you. GraphQL packages together the query language known as GraphQL, the IDL/typespec language known as GraphQL, the server spec known as GraphQL which a GraphQL-compliant server must implement [8], inside which you have to hook up your actual datastore to the GraphQL server [9][10][11][12]. It's a useful tool to build a client-server system where you're going to make a backend query in the end, but I wonder if its full potential will be realized when there are GraphQL-capable datastores to skip that extra data munging layer you have to implement yourself; but if SQL were passed on the TLS-secured wire instead of this bespoke format that no DB yet understands, would we collectively freak out? What's the difference? [1] https://www.quora.com/What-is-an-explanation-of-the-punch-line-behind-MongoDB-is-web-scale https://www.quora.com/What-is-an-explanation-of-the-punch-li... [2] https://technet.microsoft.com/en-us/library/ms191192.aspx https://technet.microsoft.com/en-us/library/ms191192.aspx [3] https://docs.oracle.com/cd/E11882_01/network.112/e40393/asojbdc.htm#ASOAG030 https://docs.oracle.com/cd/E11882_01/network.112/e40393/asoj... [4] https://www.postgresql.org/docs/9.5/static/ssl-tcp.html https://www.postgresql.org/docs/9.5/static/ssl-tcp.html [5] https://medium.com/the-graphqlhub/graphql-and-authentication-b73aed34bbeb https://medium.com/the-graphqlhub/graphql-and-authentication... [6] https://github.com/mostr/graphql-auth https://github.com/mostr/graphql-auth [7] http://stackoverflow.com/questions/34952792/how-do-i-structure-authenticated-queries-with-graphql http://stackoverflow.com/questions/34952792/how-do-i-structu... [8] https://facebook.github.io/graphql/#sec-Execution https://facebook.github.io/graphql/#sec-Execution [9] https://www.reindex.io/blog/building-a-graphql-server-with-node-js-and-sql/ https://www.reindex.io/blog/building-a-graphql-server-with-n... [10] https://www.compose.com/articles/using-graphql-with-mongodb/ https://www.compose.com/articles/using-graphql-with-mongodb/ [11] https://medium.com/apollo-stack/tutorial-building-a-graphql-server-cddaa023c035 https://medium.com/apollo-stack/tutorial-building-a-graphql-... [12] http://stackoverflow.com/questions/35940528/how-to-connect-graphql-and-postresql http://stackoverflow.com/questions/35940528/how-to-connect-g...
esfandia 10y ago
Also reminds me of CMIP and GDMO in old ITU network management standards in the mid 90s. They were RESTful, object-oriented, and you could make some pretty expressive queries with them. The standards failed probably because they were way ahead of their times: too many new concepts, too complicated compared to SNMP, and the documents were a very boring read.
- fowl2 10y ago
  Or CAML... hides
electrum 10y ago
Before GraphQL, the public Facebook APIs had FQL, which provided a SQL-like language that allowed doing server-side projections and joins: SELECT uid, name, pic_square FROM user WHERE uid = me() OR uid IN (SELECT uid2 FROM friend WHERE uid1 = me())
koko775 10y ago
No, what's old is old again. FQL was a SQL-like syntax and it was totally busted. GraphQL isn't just a structured query language, it's a query language on a unified hierarchical datastructure, and clients can make use of this hierarchy and unification to issue queries local to data and batch them to optimize query size. This in turn lets you have both an effective cache and a minimal distance between query and output to UI.

by niftich 10y ago

gjtorikian 10y ago

> Neatly coinciding with GraphQL's announcement 'Leaving technical preview' We coordinated with Facebook to do that. ;)

rottyguy 10y ago

except they removed the physical knowledge and just went with logical associations

halomru 10y ago
SQL (at least the subset used for querying and modifying data) contains no physical knowledge either. In a SELECT-query a physical table and a logical view look and behave the same. If you only give your users access to views instead of physical tables you get the same result as GraphQL, just with different syntax.
- deleted 10y ago
  [deleted]

skybrian 10y ago

The main thing is making it secure and scalable. The old client-server infrastructure for database apps was not designed to be deployed over the Internet.

niftich 10y ago
> secure and scalable > over the Internet What does this really mean? How does this substantially differ from the now-facetious term 'web scale' [1] ? Modern RDBMS'es offer encrypted communications between client and server [2][3][4], but nothing is stopping a deployer from putting a proxy between the database and the Internet-resident end-user to translate between authentication mechanisms. In fact, this happens in every single API today, where the Basic or OAuth or Cookie-Auth request comes in the HTTP body, and gets made into a database query in a query language the DB understands -- SQL or something else. GraphQL needs to you bring your own authn/z [5][6][7] much the same way that your run-of-the-mill HTTP API needs to you to bring your own authn/z, so I can't accept 'secure' as an innovation over SQL. "Scalable?" How? I genuinely think this tech is neat but let's consider what it gives you. GraphQL packages together the query language known as GraphQL, the IDL/typespec language known as GraphQL, the server spec known as GraphQL which a GraphQL-compliant server must implement [8], inside which you have to hook up your actual datastore to the GraphQL server [9][10][11][12]. It's a useful tool to build a client-server system where you're going to make a backend query in the end, but I wonder if its full potential will be realized when there are GraphQL-capable datastores to skip that extra data munging layer you have to implement yourself; but if SQL were passed on the TLS-secured wire instead of this bespoke format that no DB yet understands, would we collectively freak out? What's the difference? [1] https://www.quora.com/What-is-an-explanation-of-the-punch-line-behind-MongoDB-is-web-scale https://www.quora.com/What-is-an-explanation-of-the-punch-li... [2] https://technet.microsoft.com/en-us/library/ms191192.aspx https://technet.microsoft.com/en-us/library/ms191192.aspx [3] https://docs.oracle.com/cd/E11882_01/network.112/e40393/asojbdc.htm#ASOAG030 https://docs.oracle.com/cd/E11882_01/network.112/e40393/asoj... [4] https://www.postgresql.org/docs/9.5/static/ssl-tcp.html https://www.postgresql.org/docs/9.5/static/ssl-tcp.html [5] https://medium.com/the-graphqlhub/graphql-and-authentication-b73aed34bbeb https://medium.com/the-graphqlhub/graphql-and-authentication... [6] https://github.com/mostr/graphql-auth https://github.com/mostr/graphql-auth [7] http://stackoverflow.com/questions/34952792/how-do-i-structure-authenticated-queries-with-graphql http://stackoverflow.com/questions/34952792/how-do-i-structu... [8] https://facebook.github.io/graphql/#sec-Execution https://facebook.github.io/graphql/#sec-Execution [9] https://www.reindex.io/blog/building-a-graphql-server-with-node-js-and-sql/ https://www.reindex.io/blog/building-a-graphql-server-with-n... [10] https://www.compose.com/articles/using-graphql-with-mongodb/ https://www.compose.com/articles/using-graphql-with-mongodb/ [11] https://medium.com/apollo-stack/tutorial-building-a-graphql-server-cddaa023c035 https://medium.com/apollo-stack/tutorial-building-a-graphql-... [12] http://stackoverflow.com/questions/35940528/how-to-connect-graphql-and-postresql http://stackoverflow.com/questions/35940528/how-to-connect-g...

esfandia 10y ago

Also reminds me of CMIP and GDMO in old ITU network management standards in the mid 90s. They were RESTful, object-oriented, and you could make some pretty expressive queries with them. The standards failed probably because they were way ahead of their times: too many new concepts, too complicated compared to SNMP, and the documents were a very boring read.

fowl2 10y ago
Or CAML... hides

electrum 10y ago

Before GraphQL, the public Facebook APIs had FQL, which provided a SQL-like language that allowed doing server-side projections and joins: SELECT uid, name, pic_square FROM user WHERE uid = me() OR uid IN (SELECT uid2 FROM friend WHERE uid1 = me())

koko775 10y ago

No, what's old is old again. FQL was a SQL-like syntax and it was totally busted. GraphQL isn't just a structured query language, it's a query language on a unified hierarchical datastructure, and clients can make use of this hierarchy and unification to issue queries local to data and batch them to optimize query size. This in turn lets you have both an effective cache and a minimal distance between query and output to UI.