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.
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?
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.
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.
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
