Comment by niftich | Hacker News Reader

Comment by niftich | Hacker News Reader

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/ [2] https://neo4j.com/developer/cypher-query-language/#_about_cy... [3] http://tinkerpop.apache.org/ [4] https://www.w3.org/TR/sparql11-query/ [5] https://news.ycombinator.com/item?id=12479370#12480408 [6] http://swagger.io/specification/#pathTemplating [7] http://raml.org/developers/raml-200-tutorial#parameters

> Neatly coinciding with GraphQL's announcement 'Leaving technical preview'

We coordinated with Facebook to do that. ;)

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.

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())

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.

Or CAML... hides

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.

> 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-li... [2] https://technet.microsoft.com/en-us/library/ms191192.aspx [3] https://docs.oracle.com/cd/E11882_01/network.112/e40393/asoj... [4] https://www.postgresql.org/docs/9.5/static/ssl-tcp.html [5] https://medium.com/the-graphqlhub/graphql-and-authentication... [6] https://github.com/mostr/graphql-auth [7] http://stackoverflow.com/questions/34952792/how-do-i-structu... [8] https://facebook.github.io/graphql/#sec-Execution [9] https://www.reindex.io/blog/building-a-graphql-server-with-n... [10] https://www.compose.com/articles/using-graphql-with-mongodb/ [11] https://medium.com/apollo-stack/tutorial-building-a-graphql-... [12] http://stackoverflow.com/questions/35940528/how-to-connect-g...

I think it's secure in the sense that you can easily add in your own authentication scheme that integrates with the schema, whereas this is basically impossible if you were accepting sql statements (short of parsing them yourself, which seems more difficult than parsing GraphQl)

In a traditional RDBMS you would let the database enforce schema level authn if that was a concern, so wouldn't have to parse anything. You'd just connect to the database as the appropriate user and send the query.

I really don't think this is a practical for most rdbms, I don't think database auth schemes are built to support millions of users scenarios. I'm also not sure what sort of support there is for row level authorization.

Based on how the query executor currently works, I wouldn't call it scalable. Well sure, it can scale, but that implies that it's more efficient when it isn't in many cases. Basically the more complex your GraphQL query gets the more steps the GraphQL server has to take to resolve it, and figuring out how to combine those operations into something resembling a single SQL query isn't an easy thing to do. It scales so well for Facebook because their implementation only reads from a cache so they don't really have to worry about it.

Aggregating various data points manually in a predefined way may be less flexible than GraphQL, but it's much easier to optimize when things get complex imo

To me this is sort of like WebGL versus GL. WebGL is a security risk, but I'd still trust browser vendors to lock it down better than I trust the authors of video card device drivers who probably weren't even thinking about the possibility of hostile API calls.

Similarly, I'd expect Facebook to be thinking about Internet attacks due to real-world experience with hostile users all the time, versus a database company where the typical use case is logins from authorized employees and DBA's. They may try to get security right but it's not going to be top of mind and they have other concerns.

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

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.

Reply on news.ycombinator.com