11 comments

[ 3.5 ms ] story [ 15.8 ms ] thread
I wish GraphQL was discussed in the context of the declarative/logic programming paradigm (as in Prolog) where it belongs. Instead, it's always spinned as this "shiny new thing" and contrasted with REST, which does not add any insight imho.
Can you explain what you mean? I think it's contrasted with REST because that's where it's used, in HTTP APIs.
I like to think of GraphQL as an ORM that hides the complexity of SQL queries. It is a DSL from the logic family. That it happens to be used in web services is secondary to understanding how it works. Could be used in a different context entirely.
Ah, interesting. So you could have a RESTful API but your server uses GraphQL for the ORM layer, as you say.
> It is a DSL from the logic family

I'm having trouble seeing what features GraphQL gets from the logic family. The query feels more like a way to execute a series of function calls with parameters, like a chain of promises. You can't really encode any logic or do even simple filters like "WHERE foo < bar", beyond what arguments have been added to each field.

The essence of logic programming[0] is in enabling a particular kind of exchange. On the one hand, there's a knowlege base -- a specification of what is known in the form of facts/rules/relations. On the other, there's a quest to satisfy some goal. In particular, the query may filter the knowledge base for a particular representation of facts. The query is nothing but a problem statement. In the middle, there's an engine that deduces the answers to queries, however the implementation is hidden from the user. In the ideal world, the user does not concern herself about how the search could be performed at all. The engine would magically produce the answer. (For efficiency's sake, this is not always the case in practice.) GraphQL is built in this spirit. There's an opportunity for a more detailed blog post here. I'll see to it when I get a chance.

[0] https://en.wikipedia.org/wiki/Logic_programming

It was designed to as a better alternative to restful interfaces. It might be its own language but it is made for querying data. I don't feel it should be discussed alongside prolog, they might have similarities but they where created to solve 2 very different problems.
I definitely like the GraphQL idea, it has been out from since 2015. But the adoption and real-world application usage of GraphQL is quite low. What's the reason is GraphQL too raw or too complicated to get started with to replace REST APIs ?
This is something I've observed and would be curious to know too.
I wonder if it's the perceived complexity of building code that can serve the API endpoint