101–110 of 111 posts
Well, there's EQL and various implementations that use datalog under the hood. https://edn-query-language.org/eql/1.0.0/what-is-eql.html
This is actually fairly common in Clojure annd Clojure script. Sometimes using the Datomic DB as a backend for it. This is an older presentation but its all about doing Datalog from the client to the DB. See: https://www.youtube.com/watch?v=aI0zVzzoK_E But if you go threw the Clojure world, there is Datalog all over the place, both client and server. Check out Datascript: https://github.com/tonsky/datascript This ful…
Fulcro is defintely the go to framework. It makes use of EQL, which is a superior alternate to Graphql, for server-client communication.
However, as j-pb noted in another comment:
"GraphQL queries describe Tree unfoldings of graphs, and thus return trees.
Datalog describes recursive conjunctive queries on hypergraphs (relational model) without or limited negation, and thus return a set or bag of hypergraph edges."
TerminusDB allows you to use both approaches. Due to the way we have designed our graphs, with a strongly typed schema langage, you can extract sub-graphs as unfolded trees using a special predicate exposed in our datalog language.
This approach (hopefully) gives the best of both worlds, allowing graph traversal and extraction of objects/documents in a single framework, all communicating information via JSON-LD.
TerminusDB does use a Datalog-like language as the query language for its public web API. Datalog has long seemed to me to be the obvious "next step" for query languages as it enables richer manipulations than those provided by vanilla SQL-like languages in a clean fashion. However, as j-pb noted in another comment: "GraphQL queries describe Tree unfoldings of graphs, and thus return trees. Datalog describes recursiv…
How do I implement Datalog in my application? Crickets...
Depending on the stack, you can use some open source libraries. Datascript is quite robust, and useable from javascript/clojurescript. https://github.com/tonsky/datascript
Most uses of GraphQL is to expose existing data from a relational database through an API, so although this looks like an interesting project, is doesn't look like it would be a contender against any GraphQL implementation.
I'd argue there are two faulty assumptions in the OP: 1. "GraphQL serves the same use case as Datalog.", and 2. "Datalog is better at that use case."
GraphQL is not a general purpose query language! There are practically no query operations at all built into the specification - it's all about field selection and parameter passing. At heart it's more like a RPC protocol geared towards requesting tree-like data. You would evaluate GraphQL against options like plain REST, OpenAPI, gRPC, not against Datatalog.
A more relevant question to ask is why Datalog never took over for SQL, but it would be harder to pretend that SQLs dominance is due to it being the current passing fad.
Earlier quoted context omitted.
>> 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://arx…
Agreed about the definitions of decidability and formal correctness. Agreed also about the expressivity of the pure subset of Prolog. Oh, I remember now about Datalog and deciding equality. Yes. Well. You hit these kinds of walls anytime you try to do anything intersting with logic above the propositional level. The history of logic programming is a history of one negative result after the other and the compromises that must be made to avoid them. C'est la vie.
But we persist because there is a pot of gold at the end of the rainbow and what best way is there to spend your life than chasing rainbows? :0
>> 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.
Yes, I agree absolutely about that.
For example, my code doesn't _need_ the impure constructs. But it's a lot more efficient with them. So it's a trade-off. And a trade-off very common in Prolog which, to my opinion makes many pragmatic choices that sacrifice purity for the benefit of having a useable language.
That goes for reasoning about correctnes, also. The fact that you can sometimes reason about program correctness, given you can accept some restrictions to what kind of programs you can reason about is already miles ahead from what is possible with anything that isn't a logic programming language. That has to count for something.
>> 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. ^^'
Aw, I enjoy writing Prolog. So much so that I left my lucrative career in the industry to do research that would let me write a lot of it :)
Earlier quoted context omitted.
Per the last comment, please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing any action creators or action types by hand: https://redux-toolkit.js.org Not saying it's a replacement for Apollo (since Redux itself doesn't…
Still requires boilerplate for thunks, which in my case is most redux actions. Also I think you still don't support for specifying same reducer for many actions (for example as an array - https://github.com/piotrwitek/typesafe-actions ). The immutable update logic however is amazing and I am glad I got introduced to it by you!
And yes, `createSlice` explicitly supports responding to actions that were defined elsewhere in the app, using the `extraReducers` argument:
https://redux-toolkit.js.org/api/createSlice#extrareducers
Although... are you saying that you want one reducer function to handle many different actions in one slice? Just define the reducer outside the slice itself, and pass it as the handler for each action:
createSlice({
name: "someSlice",
initialState,
reducers: {
action1: someCaseReducer,
action2: someCaseReducer,
}
})
Well, there's EQL and various implementations that use datalog under the hood. https://edn-query-language.org/eql/1.0.0/what-is-eql.html
EQL is surely a great alternative to Graphql because of namespaced keywords and rich data structure (in contrast of Graphql's string base). It is also inspired by Datomic's Pull API. However, it's a specification and the most popular imlementation (Pathom) has nothing to do with Datalog.
It's more like:
Pathom vs GraphQL-based API (vs REST)
and
Datalog vs SQL (vs NoSQL)
The mainstream is in the process of migrating from REST to GraphQL, but I think Pathom could be the black horse in this race. Just watch the last part of Wilker Silva's The Maximal Graph talk to see the potential: https://youtu.be/IS3i3DTUnAI?t=2080
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…
GraphQL doesn't do anything that you can't do with sufficient coordination, but coordination is actually one of the hardest parts of getting things done at a large company.
Earlier quoted context omitted.
The options are not only GraphQL vs REST. In a lot of cases, you can also render server side and push just plain html / components to the client instead.
Aren't you just moving the client to the backend here? As I understand it we are talking about how whoever needs to render the data gets the data. GraphQL vs. REST vs. whatever is still as relevant in the backend-rendered case.
From your angle, I guess one other alternative to GraphQL and REST would be RPC. ;)