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

21–30 of 111 posts

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

#21

Post by kumarvvr »

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…

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

Then I realised, why cant I simply group those multiple query calls into one giant post request, with custom codes for querying or mutation, send a post request with a body that is a DSL i have thought of, and let my backend decode that DSL and send the replies. No longer would I be limited by URL structure, no longer would I have to make multiple query calls for getting a complex nested entity.

The only downside is that I have to docume t it more thoroughly and that my api does not have easy discoverability.

But since I have only one client, my frontend that I program,this is not an issue.

After pondering over the DSL a bit, I realised I am actually conceptualizing GraphQL.

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

#22

Post by qeternity »

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.

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

#23

Post by barrkel »

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

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 stuff you want to deprecate, well, the complexity just comes back; it's just in the code handling those custom codes, and all you've invented is a multiplexer that obscures the complexity.

I think there's value to it though, to GraphQL, but mostly on the read side rather than CUD side. Often all sorts of widgets need to knit together data from different sources, and if your data is relational under the hood, with REST endpoints per relation, the knitting is work better left to a library. I'm less convinced for updates.

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

#24

Post by thom »

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…

For what it's worth, if I saw Datalog on a CV I would think "has studied the ways of the old masters" and when I see GraphQL I think "blub". But I don't claim to be good at hiring.

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

#25

Post by refset »

thom wrote: post #5
patrickmn wrote: post #3

Earlier quoted context omitted.

What's the best example of modern Datalog?

Datomic. Also interesting: https://github.com/sixthnormal/clj-3df

Datomic provides a fantastic range of query features, but the underlying Datalog engine does have drawbacks in how it evaluates results eagerly and requires intermediate result sets to fit in memory [0].

For comparison, I work on https://opencrux.com which uses lazy Datalog evaluation and can spill to disk when necessary. Naturally there are downsides to this approach also, including a dependence on seek-heavy use of local KV indexes.

clj-3df is definitely interesting although not strictly comparable :)

[0] https://docs.datomic.com/on-prem/query.html#memory-usage

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

#26

Post by vailripper »

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…

GraphQL actually makes a fantastic frontend for a microservices architecture. We have several GRPC services that drive a suite of applications, we wrap those in a graphql schema and we've now made consuming those services much easier while maintaining the original underlying services.

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

#27

Post by beaker52 »

eurasiantiger wrote: post #14
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 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 actual end to end solution - if anything it gives you more.

It's marketed at front end devs, who in my experience, really love _easy_ solutions, rather than simple.

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.

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

#28

Post by shantly »

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 building an unbounded number of front end clients which will consume a complex data model. And unless both of those things are true, GraphQL is going to cost you more than the value it adds.

That matches my impression. Frankly I don’t think it’s very interesting. But damned if 3/4 the webtech-focused job postings I see don’t list “graphQL experience” under the nice-to-haves.

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

#29

Post by thom »

refset wrote: post #25
thom wrote: post #5

Earlier quoted context omitted.

Datomic. Also interesting: https://github.com/sixthnormal/clj-3df

Datomic provides a fantastic range of query features, but the underlying Datalog engine does have drawbacks in how it evaluates results eagerly and requires intermediate result sets to fit in memory [0]. For comparison, I work on https://opencrux.com which uses lazy Datalog evaluation and can spill to disk when necessary. Naturally there are downsides to this approach also, including a dependence on seek-heavy use of…

Oh hello! I hadn't realised JUXT had their own products now, will definitely check this out.

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

#30

Post by zo1 »

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

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.

Post reply on HN