4 ms·
I've written an interface similar to GraphQL some time before it was made public using JSON to describe the desired data tree, filters, etc. The real upside of
by ht85 10y ago
I've written an interface similar to GraphQL some time before it was made public using JSON to describe the desired data tree, filters, etc.
The real upside of GraphQL is that it has become popular enough that there are parsers in most languages, and that you don't waste time designing and testing a new standard. If you use it for a public API, you can also simply point people to the existing documentation.
It's definitely not a widely accepted standard, but still better than rolling your own!
- untog 10y agoA question from someone that has never used GraphQL: what makes it better than SQL? You don't even need parsers in different languages for SQL, you could just send it straight to the DB. But I assume I'm missing something.
- RussianCow 10y ago> You don't even need parsers in different languages for SQL, you could just send it straight to the DB. You probably don't want to do that for security reasons. So either way you need a parser, and at that point, it makes sense to use something that is database agnostic and allows you to model relationships without complex joins or otherwise exposing the internal representation of the data.
- vcarl 10y agoClients can use it to request exactly what they need. Since it's a graph, you can just keep grabbing nodes to get the fields you need in the shape that works for your client. GitHub added a GraphQL endpoint for their API, the improvements they cited were reduced overfetching of data the client didn't use e.g. urls to linked resources, and fewer underfetches e.g. using the results of the first request to populate a second or third request. http://githubengineering.com/the-github-graphql-api/ http://githubengineering.com/the-github-graphql-api/ It's not really GraphQL vs SQL, it's GraphQL vs RESTful APIs.
- ht85 10y agoYou might be confused by how PostGraphQL works, as it makes the queries very close to the database structure. In real life there will usually be a lot more going on to serve a GraphQL query than simply translating it to SQL. The data you'll send might come from many different sources, including any kind of database, caches, or just constants in your code. As commented here, permissions over data is a big topic, and if you were accepting raw SQL, you'd have to parse / tokenize it, and somehow validate it before executing it. This is what GraphQL does, but instead of trimming down and restricting the usage of SQL, it defines a language that is similar, close to being a subset of it, with a much simpler syntax.
- vbezhenar 10y agoYou can allow predefined SQL strings and define security rules for each string. If you need new query, you have to write new security rule for it. Won't work for dynamically generated SQL, but for most CRUD SQL it should work.
- dkersten 10y agoIf you have N predefined SQL queries, then why not just wrap them in REST endpoints (it sounded to me that untog was suggesting that SQL be the interface to the data). If the user can write whatever query they want, then validating by string isn't really a good idea...
- softawre 10y agoI have done this same, rolling my own. We copied a popular public API, LinkedIn I believe. We called it "api selectors".