Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why GraphQL APIs but no Datalog APIs?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 111 posts

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#51

Post by watwut »

shantly wrote: post #7
Etheryte wrote: post #4

For 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…

> If you only expect one client (or a few very similar ones) and you want GraphQL-like division of labor just have your frontend and backend folks actually talk to each other and maybe have the backend folks also write a client library for their services (my preference, most of the time).

Yeah, but same result is much easier faster with graphql. When frontend developer can in most cases just slightly tweak the query, then it takes less time then having to talk to backend developer and wait till backend developer even starts working on it.(I am assuming that backend developer is normally occupied and is not sitting around bored until frontend developer needs query.)

And also, it avoids friction when backend developer is one of those superstars who are difficult to talk with.

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#52

Post by rklaehn »

We currently looking for a powerful query language for a distributed event sourcing system. It would have to be embeddable in rust.

Is there a site where I can see more complex datalog queries and how they compare to other query languages? All the examples I have found so far were relatively trivial and basically just assumed that you knew that datalog was super powerful.

A comparison of how to solve problem X, Y, Z in datalog, graphql and SQL would go a long way to convince people that it is a superior alternative.

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#53

Post by JMTQp8lwXL »

Etheryte wrote: post #4

For 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…

This assumes the backend teams are even ready to offer HTTP/2 for us. For some reason or another, we're stuck at HTTP/1.1 since we are fronted by a certain CDN provider and our process for change management in that tool is skittish, since the rules grew organically and making changes is now tough.

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#54

Post by JMTQp8lwXL »

andrewingram wrote: post #11

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.

jQuery, for its time, fit well its architecture and those familiar with it were extremely productive. Doesn't necessarily mean something is a great paradigm.

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#55

Post by JMTQp8lwXL »

dzonga wrote: post #12

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

React came out in 2013. That's six years and counting of "hype".

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#56

Post by maweki »

mycall wrote: post #40
triska wrote: post #6

Earlier quoted context omitted.

A good way to try Datalog is to use a state-of-the-art Prolog system that supports SLG resolution (tabling). SLG resolution is an evaluation strategy of Prolog programs that provides favourable termination properties compared to SLDNF resolution which is Prolog's default execution strategy. A great example for this is XSB Prolog, since it has pioneered and refined many of these techniques and serves as an example and…

A turning complete query language sounds like a recipe for DoS attacks.

It is only Turing complete if you allow new rules. Usually a client would only be allowed to formulate query goals.

In that sense, GraphQL is Turing complete as well, as the underlying implementation could just simulate a Turing machine.

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#57

Post by acjohnson55 »

It's not clear to me that GraphQL and Datalog solve the same problems. GraphQL, to me, is fundamentally about designing the interface between a client and server, decoupled from the logic that satisfies requests. I think it's actually not a query language at all, any more than HTTP is a query language. Datalog is very much a query engine. And it's not super clear to me that the services exposed by a server map cleanly to a logic model. GraphQL requires no such purity.

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#58

Post by rienbdj »

sundbry wrote: post #39
zo1 wrote: post #18

Earlier quoted context omitted.

> "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 the…

You can handle proper URLs in a SPA if you know what you're doing. It's not something your average frontend dev would pay attention to though, sadly. Server-side "isomorphic" rendering of pages is also possible but a lot more complicated to resolve all the async requests that have to run to render the page.

Unless you use GraphQl of course!

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#59

Post by [deleted] »

triska wrote: post #2

That'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…

[deleted]

Re: Ask HN: Why GraphQL APIs but no Datalog APIs?

#60

Post by arvinsim »

hamandcheese wrote: post #31
shantly wrote: post #7

Earlier 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…

The big win of using GraphQL, at least for me, is not the performance, but the developer experience. I can craft a query in Graphiql, paste it into my application, and from there generate Flow types for the query response. Make a breaking change to my graphql API? Flow types will fail CI tests until I fix any dependent client code. All of this works pretty nicely out of the box, and it’s leaps and bounds better than…

You mean frontend developer experience. The backend developers I interact with are not too enthusiastic on moving the complexity from the frontend to the backend when using GQL.
Post reply on HN