Ultimately GraphQL is popular because the query ergonomics fit well with the component architecture everyone is using these days, and once you're familiar with it you can be extremely productive.
Ask HN: Why GraphQL APIs but no Datalog APIs?
11–20 of 111 posts
Re: Ask HN: Why GraphQL APIs but no Datalog APIs?
#12I will say something that is commonly known. a lot of frontend software dev revolves around hype. if React is the in thing and fb dev's are promoting Graphql, then everyone will go towards that. I don't know much about Datalog, but JSonAPiSpec meets most of things that people tout Graphql for. + if you're a person trying to keep employed then you've to follow the trends .
Re: Ask HN: Why GraphQL APIs but no Datalog APIs?
#13That's a very justified question! In my opinion, Datalog or — more generally — Prolog is where many querying APIs will eventually arrive, because this syntax has many nice advantages: It is very convenient, expressive and readable, programs and queries can be easily parsed and analyzed with Prolog's built-in mechanisms, there is an ISO standard for it etc. When semantic web formalisms were discussed, Prolog was somet…
This was (is?) what the semantic web dream was all about, and I find it funny that it took a corporation (FB) developing a clone before others discovered the concept. Semantic web data would be published as RDF data and clients would consume this data using a SPARQL query engine to get whichever shape of data that they desired.
To clarify: I mean that Prolog was under consideration to be used for what SPARQL was then developed, as a more readable and simpler query and also modeling language.
Several researchers working in this area considered the development of SPARQL to be a missed opportunity for better formalisms, since Prolog could have been used instead.
And, yes, to many who have worked with RDF, SPARQL and the various notations that have been developed for semantic web technologies, Prolog seems like a dream that shows what these technologies could have been, and can become in the future, i.e., easily processable, with a uniform and simple syntax that already has an ISO standard, and amenable to formal reasoning based on well-known logical rules.
Re: Ask HN: Why GraphQL APIs but no Datalog APIs?
#14For context, I'm a frontend development lead who oversees a number of projects of different shape and size. My personal and very subjective opinion is it's simply hype. If you say "Datalog" to a frontend developer, they will either hear "obsolete" or just not know what you mean. If you say "GraphQL", they hear "+5 CV points". Obviously that is slightly tongue in cheek, but the marketing side of it is a very real fact…
> I'm sure they exist out in the wild, but personally I haven't seen a project where GraphQL really shines through. In my experience, HTTP2 and reasonably well designed RESTful endpoints are the right default to go with. There is the argument that building good APIs is hard, but I believe someone who has reasonable experience with a stable technology will outperform someone using a new tool for the job. If you're not…
GraphQL makes a ton of sense when your queries use data from multiple different and possibly interdependent source APIs. It allows you to hide all manners of ugly hacks behind a single, neat, cacheable endpoint that can even act as a normalisation layer.
Re: Ask HN: Why GraphQL APIs but no Datalog APIs?
#15Ultimately GraphQL is popular because the query ergonomics fit well with the component architecture everyone is using these days, and once you're familiar with it you can be extremely productive.
sorry not a frontend dev, where can i get basic info about 'component architecture'
Re: Ask HN: Why GraphQL APIs but no Datalog APIs?
#16Prolog (Datalog) has always been the gold standard for query languages. GraphQL is merely the latest attempt to reinvent it by people who obviously don't know what came before (or don't care). This might be because CS programs are no longer teaching Prolog, but I think it's more likely because one doesn't get career advancement points for using something "old" unless one reinvents it and renames it so it seems "new."
Re: Ask HN: Why GraphQL APIs but no Datalog APIs?
#17Hyperfiddle (my startup) is a datalog API experiment, wrapped up in a low-code tool. We vertically integrate Datomic, a datalog database for AWS. Can you imagine GraphQL ever being low-code?
https://gist.github.com/dustingetz/654e502340070280ab9744723...
Re: Ask HN: Why GraphQL APIs but no Datalog APIs?
#18For context, I'm a frontend development lead who oversees a number of projects of different shape and size. My personal and very subjective opinion is it's simply hype. If you say "Datalog" to a frontend developer, they will either hear "obsolete" or just not know what you mean. If you say "GraphQL", they hear "+5 CV points". Obviously that is slightly tongue in cheek, but the marketing side of it is a very real fact…
> I'm sure they exist out in the wild, but personally I haven't seen a project where GraphQL really shines through. In my experience, HTTP2 and reasonably well designed RESTful endpoints are the right default to go with. There is the argument that building good APIs is hard, but I believe someone who has reasonable experience with a stable technology will outperform someone using a new tool for the job. If you're not…
> "GraphQL doesn't make a ton of sense to me, unless you're expecting many clients with significantly different query pattern requirements and prefer to take on performance and (maybe) security uncertainty & complexity to accommodate that more easily."
My impression of it is that it's an "API" that's masquerading as a dumb relay, essentially giving almost datastore-level access to the frontend client (even though they don't market it that way). And this is done so that "Frontend devs" can just do "Frontend" things with access to all the data they might end up using. A bit snarky, but I do see it as a way to just "offload" the problem down the line, instead of thinking about the API-usage and what it means for potential frontend clients. That's the "old way" of doing things of course.
It fits in to the rest of the "movement" or trend currently happening: Thick (web) clients that do everything and the kitchen sink (including auth. See JWT in arb HTTP headers instead of cookies), SPAs so that there is no server side page rendering (this must all be done in the thick web client you see), document databases instead of SQL so the "frontend" devs don't have to worry about schemas, SPAs so that we break half the bloody internet because we now need to retrofit browser navigation using hashtags, everything has to be an "API" now because we can't convey data using server-rendering, etc.
Honestly, just that navigation thing alone is nuts and I can't believe we ever allowed it to be imposed on us. At this point, I'm afraid to touch those buttons on a new website without first trying them to learn their specific behavior on that site.
Re: Ask HN: Why GraphQL APIs but no Datalog APIs?
#19Ultimately GraphQL is popular because the query ergonomics fit well with the component architecture everyone is using these days, and once you're familiar with it you can be extremely productive.
>GraphQL is popular because the query ergonomics fit well with the component architecture everyone is using these days
Were they using that architecture prior to moving to GraphQL, or did the tail wag the dog in most cases?
Re: Ask HN: Why GraphQL APIs but no Datalog APIs?
#20Earlier quoted context omitted.
> I'm sure they exist out in the wild, but personally I haven't seen a project where GraphQL really shines through. In my experience, HTTP2 and reasonably well designed RESTful endpoints are the right default to go with. There is the argument that building good APIs is hard, but I believe someone who has reasonable experience with a stable technology will outperform someone using a new tool for the job. If you're not…
GraphQL makes a ton of sense when your queries use data from multiple different and possibly interdependent source APIs. It allows you to hide all manners of ugly hacks behind a single, neat, cacheable endpoint that can even act as a normalisation layer.
I don’t get why GraphQL would be better at that particular use case than anything else, really. Capable of it, sure, but shifting the query-crafting to the client doesn’t really have any effect on that problem.
[edit] I just mean it seems unrelated to that problem, as far as I can tell.