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

91–100 of 111 posts

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

#91

Post by tuesdayrain »

arvinsim wrote: post #60
hamandcheese wrote: post #31

Earlier quoted context omitted.

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.

From my experience the backend also becomes simpler because it standardizes a lot of patterns, especially regarding subscriptions. I have a feeling any backend developer that thinks GraphQL is a significant increase in complexity is just reluctant to learn a new technology.

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

#92

Post by YeGoblynQueenne »

tastroder wrote: post #90
YeGoblynQueenne wrote: post #77

Earlier quoted context omitted.

That sucks. XSB is old code and I believe it was meant mostly as a proof of concept even at the time it was written. I doubt many people use it, even in research, nowadays. I believe what triska meant about XSB is that it demonstrated the benefits of SLG resolution, by being a proof of concept like I say. So yes, XSB would be more of academic interest. If you want a modern Prolog to play around with you should try Sw…

Much appreciated, I kind of got what triska meant (didn't realize they were a contributor to that project), I just wanted to highlight that this is a real barrier for adoption of these alternative stacks. I find this interesting enough to spend more than those 10 minutes when I have time, sure. It's just that a random dev on the search for some component to solve something in their stack likely wont. Just gave the SW…

I agree, it's very bad to have to go through so much hassle when you just want to have a quick look to evaluate a possible tool for a problem you have right now. This is a difficult situation to resolve: usabiity won't improve until there's more users and until usability improves there won't be more users.

I'm glad you like Swi. It's not the fastest implementation but it's certainly the one with the largest community and the most quality-of-life features, documentation server, unit tests library, package manager etc. I love it :)

>> (And btw, my bad about the Perl comment, I just realized when setting up the SWI one that they seem to share a file extension with Perl.)

Oh yes, I totally forgot about that (can't say I use much perl!). It can look funny if you don't expect it :)

Anyway I hope you have time to look into the language more in the future. Like I say, it's hard to learn but it's worth the pain.

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

#93

Post by YeGoblynQueenne »

j-pb wrote: post #86
YeGoblynQueenne wrote: post #83

Earlier quoted context omitted.

That's right- Prolog is not a query language. But the claim I believe is that _Datalog_ is a subset of Prolog that is a query language. That claim is true by design. Also, given bottom-up evaluation, Datalog programs are guaranteed to terminate and, restricted to definite clauses with no function symbols (of arity more than 0) they are also amenable to formal proofs of correctness, perhaps more so than Prolog itself.…

Sure Datalog is a query language, but Prolog isn't. I object to datalog being viewed as a subset of prolog, other than for historical reasons. It's just not useful as both languages differ significantly in philosophy, properties and implemenentation. Datalog program equality is undecidable btw so while it's certainly more amenable to correctness proofs than prolog (which isn't at all with it's undecidability and impl…

>> Edit: Some systems that arguably implement a superset of Datalog, but for which their Datalog subset is not a subset of Prolog are LogicBlox, Datomic, Datascript and TriQ-Lite.

That's interesting, I didn't know about that. I might have a look now that you mention it.

Regarding correctnes proofs, I think triska knows this subject better than me but my understanding has always been that if you stay within the pure subset of Prolog (i.e. no destructive update of terms, no reads and writes to the database and basically nothing with side-effects) then you can actually fully reason about your programs at least in principle.

I see this in practice everytime I write an extensive piece of Prolog code (for the record, I do that a lot, for my PhD) and I end up using the assert/1-retract/1 mechanism to update the program database as the program runs. The problem with that is that it kicks you right out of the cozy world of immutability, right back to the world of programmig with mutable states. Once your program reaches a certain degree of complexity it becomes impossible to predict its state at any given point in time. [Edit: the reason is that if something goes wrong and your program fails unexpectedly, the program database is left in an unpredictable state - and you have to understand each such state with great precision or it all goes to hell in a handcart. You're back to doing memory allocation by hand basically].

The hurt I feel everytime I use the assert/retract mechanism, or rather, the difference between the level of pain using assert/retract compared to not using them, is, for me, a great measure of the extent to which pure Prolog code is predictable. I'd even say amenable to formal proofs of correcntess but I've never actually tried that, to be fair.

As to decidability, my understanding is that you can either have Turing completeness, or decidability, but not both. So to slightly correct my comment from above, Datalog itself is decidable only given a finite constant and predicate signature (the set of constants and predicate symbols). But finiteness means incompleteness.

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

#94

Post by andrewingram »

rhizome wrote: post #19
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.

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

I can't speak for everyone, but in my case it's "yes". I'd also be fairly comfortable claiming that there are a lot more people using component architectures (React, Vue, Elm, Ember and Angular) than are using GraphQL.

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

#95

Post by jcadam »

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…

I sort of agree. GraphQL just seems like a solution for a small set of niche problems that's being promoted as a general REST replacement for any and all web APIs.

Seems like we (as in, our industry) went through this before with everyone ditching relational databases and glomming onto NoSQL (particularly MongoDB) - only to realize later it was a mistake.

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

#96

Post by scotty79 »

For me the most important thing about graphql is composability.

Child component can communicate their data requirements to the parent and parent can include them in the query and feed the data to the children as it arrives.

Don't know if Datalog has anything for that.

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

#97

Post by j-pb »

YeGoblynQueenne wrote: post #93
j-pb wrote: post #86

Earlier quoted context omitted.

Sure Datalog is a query language, but Prolog isn't. I object to datalog being viewed as a subset of prolog, other than for historical reasons. It's just not useful as both languages differ significantly in philosophy, properties and implemenentation. Datalog program equality is undecidable btw so while it's certainly more amenable to correctness proofs than prolog (which isn't at all with it's undecidability and impl…

>> Edit: Some systems that arguably implement a superset of Datalog, but for which their Datalog subset is not a subset of Prolog are LogicBlox, Datomic, Datascript and TriQ-Lite. That's interesting, I didn't know about that. I might have a look now that you mention it. Regarding correctnes proofs, I think triska knows this subject better than me but my understanding has always been that if you stay within the pure s…

Out of the examples I would take a look at the LogicBlox Stuff, they gave join algorithm research a big push with their Leapfrog-Triejoin.

The following papers ascend in difficulty, and are based on each other, but offer a fascinating glimpse into the connection of DPLL SAT solving and Conjunctive Query evaluation.

https://openproceedings.org/2014/conf/icdt/Veldhuizen14.pdf

https://arxiv.org/abs/1310.3314

https://arxiv.org/abs/1404.0703

As for reasoning and decidability, I think we need to clarify the decidability we're talking about. Decision problems are decidable or undecidable, and when one talks about decidability for a logic one usually means the decision problem wether a given formula of the logic is valid or not.

Everything finite is always decidable, because you can just enumerate all possibilities. And logics without negation (like Datalog without stratified negation) are generally (?) decidable because you can just construct a Herbrand interpretation accordingly.

However when we talk about correctness and formal reasoning there are other decision problems which are relevant, most of them revolve around stuff like "does this program implement this specification?", "does this program terminate?", "is this program keeping these invariants?", "are these two programs equal?"

Note that even if these problems are undecidable, it doesn't mean that they're always undecidable, just that they're not decidable in general, e.g. the halting problem is undecidable, but I can give you infinitely many turing-machines which always halt.

The pure side effect free fragment you describe is still at least as (?) powerful as FOL, even HOL if you include the meta predicates like call, thanks to the build-in predicates like forall. Heck I guess the build-in arithmetic alone will cost you decidability (of validity).

Datalog is even more restricted than what you describe and equality of two Datalog programs is not decidable according to https://core.ac.uk/download/pdf/82609701.pdf

So the question is, how much reasoning a.k.a. how many decision problems can you actually do/solve on Datalog and Prolog. For Datalog, I'd say quite a bit, but not everything, and for Prolog I'd argue very little. But both give you a lot of power in return and that's the price you have to pay.

Edit: And yeah, I don't envy you, on having to work with side-effectful prolog code. At some point it's just writing C with extra steps, ground through the Warren Abstract Sausage Machine. ^^'

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

#98

Post by 33degrees »

arvinsim wrote: post #60
hamandcheese wrote: post #31

Earlier quoted context omitted.

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.

Personally, as a full stack developer I prefer having the complexity on the back end, as I find it easier to manage there.

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

#99

Post by kumarvvr »

AlphaSite wrote: post #82
barrkel wrote: post #23

Earlier quoted context omitted.

The complexity is just moved somewhere else; instead of being explicit in an API, it's implicit in a behaviour. If you want to permission those bits you're doing CRUD ops on, or refactor how they're stored, change their normalization in the database, split them out of a monolith into separate services, ensure you're not permitting the UI team (or worse, your customers writing direct to your API) take dependencies on…

I think the issue is more with framing. GraphQL is excellent for when you’re implementing an external facing api or a data focused api. Internal APIs where you also own the client or have operation (side effect) heavy clients. These imo would be far better suited to REST.

In addition to my other reply, it serves well to finely granularize an external facing API so that consumers can mix and match to their requirement. This granularity is best accomplished by a REST Api.

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

#100

Post by shantly »

tuesdayrain wrote: post #91
arvinsim wrote: post #60

Earlier quoted context omitted.

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.

From my experience the backend also becomes simpler because it standardizes a lot of patterns, especially regarding subscriptions. I have a feeling any backend developer that thinks GraphQL is a significant increase in complexity is just reluctant to learn a new technology.

It's a shift from supporting some defined, limited set of behavior to supporting a much broader set of possible behavior, to the point that it likely can't practically be fully enumerated. If that's somehow not the case, then I'm not sure what you're using GraphQL for, since that's its whole thing.

Of course that's more complex.

Post reply on HN