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

61–70 of 111 posts

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

#61

Post by Xelbair »

zo1 wrote: post #18
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…

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

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

Or to take into the account that you have no idea what people actually use your API for. Lately i had to write an simple reporting site(simple, as i work with backend and GIS mostly) - using an existing API.

I need a fraction of data sent by API, but in bulk - it doesn't support that, nor i can change it.

Currently i do have to make a bulk requests that includes filters on the query, then i do need to individually request each record - as bulk API does not return the bloody two extra fields i need.

It turns a single query into N queries - which is slow and annoying as server cannot handle being hammered by thousands of rest API calls. Not to mention that i literally need 4 fields out of like 40.

If the app implemented graphQL it would be a breeze to just fetch what i need instead of waiting minutes(!).

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

#62

Post by hmcdona1 »

dominotw wrote: post #15
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.

sorry not a frontend dev, where can i get basic info about 'component architecture'

Modern SPA frameworks are usually built on components. You can combine components to define a tree of elements that represents your UI. This pattern is also often referred to as a Declarative UI pattern.

GraphQL works well with declarative UIs, because you can define fragments and combine them to create queries that best match the data the current set of components you are loading require. In this way, it's flexible in a way REST isn't (at least typically) and syncs well with Declarative UIs.

I can't speak to datalog though.

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

#63

Post by [deleted] »

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.

[deleted]

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

#64

Post by onion2k »

maweki wrote: post #56
mycall wrote: post #40

Earlier quoted context omitted.

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.

What I read from your post here is that GraphQL is safe by default and would require effort to make it dangerous while Datalog is dangerous by default and would require configuration to make it safe. I know which one I'd rather put on a server.

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

#65

Post by erik_seaberg »

dreamcompiler wrote: post #16

Prolog (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."

I know Prolog (from college) and SPARQL (from hobbyist dinking around with SemWeb). I love DSLs and weird languages. I should be almost the ideal Datalog user, so how did it stay completely off my radar until this post?

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

#66

Post by korla »

je42 wrote: post #48
kumarvvr wrote: post #42

Earlier quoted context omitted.

After years of programming, I am convinced that complexity cannot be overcome. For any non-trivial application, complexity is inevitable. In my view, we, as developers, should take up complexity, so that the user is unburdened from it. Ultimately, that is the value addition of software. Remove complexity and improve productivity. Fundamentally, data is relational and hierarchical, no matter how we store it (Documents…

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.

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

#67

Post by maweki »

onion2k wrote: post #64
maweki wrote: post #56

Earlier quoted context omitted.

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.

What I read from your post here is that GraphQL is safe by default and would require effort to make it dangerous while Datalog is dangerous by default and would require configuration to make it safe. I know which one I'd rather put on a server.

You have read that incorrectly. A Datalog/Prolog query does not define new rules. That's like calling arbitrary code on remote machines. You would never allow that.

But IF you were allowed to define new rules, THEN you could simulate a turing machine or create infinite reductions.

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

#68

Post by damidekronik »

acemarke wrote: post #35
qeternity wrote: post #22

As a company that runs both Django Rest Framework and GraphQL backends, there is one phenomenal argument in favor of GQL: Apollo Client. When you just want a simple, normalized reactive data store it’s really amazing (even though the Apollo kids seem to break it with every minor release). Loads of redux boilerplate go right out the window.

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!

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

#70

Post by vnorilo »

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…

Github's api [1] makes sense to me - there are lots and lots of query patterns and the previous Rest api results in quite a bit of link chasing and bandwidth burning.

It would actually be interesting to see if someone could design a very good Rest api for gh-like usage.

1: https://developer.github.com/v4/

Post reply on HN