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

41–50 of 111 posts

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

#41

Post by ng12 »

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…

Many years ago I worked at a company that had built a janky version of GraphQL in-house. The model fit our use case perfectly: our customers were dealing with a complicated ontology of objects and it allowed us to build new UIs on top of that data without implementing new REST apis. Of course our implementation wasn't the best but for a certain class of applications the graph-query model is a godsend.

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

#42

Post by kumarvvr »

barrkel wrote: post #23
kumarvvr wrote: post #21

Earlier quoted context omitted.

A few weeks ago, I was pondering over the pain involved in designing and implementing a REST api, for an simple backend. After much deliberation, it was clear to me that I dont understand the HATEOS part of REST and that I have been using the url as a filter and get or post parameters as variables for calling some functions on the backend server. And often, for an SPA, I would have to do multiple queeies in quick suc…

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…

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 / SQL). The value added by GraphQL, and often touted in documentation, is that the client, has control over the shape of the data received from the server. Though packaged in a slightly easier to read syntax, GraphQL is essentially SQL. Sending a GQL query is fundamentally sending an SQL query set, with joins and where clauses, and having a layer of abstraction that understands the query and converts it into lower levels calls to data storage systems.

In my view, this is a more powerful syntax and more flexible than using a REST API. To achieve the same with REST calls, you would have to do something akin to multiple simpler SQL queries, with manual linking of relational data.

I am sure, there will be more innovation in this area, particularly with pairin GQL with Document databases.

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

#43

Post by jholman »

beaker52 wrote: post #27
eurasiantiger wrote: post #14

Earlier quoted context omitted.

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.

What you've said is true of any aggregating intermediate API, graphql or not. If you don't want to make n calls, you make a single API endpoint that makes two calls for your one, just like when you compose functions in code. You don't need GraphQL for this. GraphQL only really brings a novel way of defining what data you want. That's it. GraphQL fixes none of your data fetching problems if you're responsible for the…

> As far as I can see, there is precisely one scenario where GraphQL makes sense - and that's where you are trying to build a lot of separate frontend clients which will consume the same large, complicated data model. And unless both of those things are true, GraphQL is going to cost you more than the value it adds.

Exactly

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

#44

Post by fulafel »

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.

Do you feel GraphQL is better than Datalog here?

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

#46

Post by muydeemer »

patrickmn wrote: post #3
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…

What's the best example of modern Datalog?

You might want to check out Grakn (https://github.com/graknlabs/grakn/) - its query language is an implementation of recursive datalog with negation and comes with lazy execution. I am one of its developers.

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

#47

Post by tirpen »

zo1 wrote: post #30
kumarvvr wrote: post #21

Earlier quoted context omitted.

A few weeks ago, I was pondering over the pain involved in designing and implementing a REST api, for an simple backend. After much deliberation, it was clear to me that I dont understand the HATEOS part of REST and that I have been using the url as a filter and get or post parameters as variables for calling some functions on the backend server. And often, for an SPA, I would have to do multiple queeies in quick suc…

Sounds more like SQL, if you ask me. Either that or something more like OData.

Or datalog.

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

#48

Post by je42 »

kumarvvr wrote: post #42
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…

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.

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

#50

Post by Aeolun »

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…

If you are trying to attach a lot of different API’s together in a consistent way, a graphQL API may be what you need.
Post reply on HN