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

31–40 of 111 posts

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

#31

Post by hamandcheese »

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…

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 my past experience with homegrown rest APIs.

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

#32

Post by treve »

hamandcheese wrote: post #31
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…

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…

It's a great thing to have! We do the same with json-schema converted to Typescript.

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

#34

Post by hawkice »

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'

He's talking about the recommended use of things like React or Elm. React will probably have the basic info that ties it to GraphQL the closest, given the creators.

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

#35

Post by acemarke »

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 provide anything around data fetching), but we specifically created RTK to eliminate the concerns around "Redux boilerplate".

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

#36

Post by leetrout »

dustingetz wrote: post #17

Hyperfiddle (my startup) is a datalog API experiment, wrapped up in a low-code tool. We vertically integrate Datomic, a datalog database for AWS. Can you imagine GraphQL ever being low-code? http://www.hyperfiddle.net/ https://gist.github.com/dustingetz/654e502340070280ab9744723...

That is really cool. I’ll have to check this out this week.

FYI Your HTTPS cert is tied to cloudfront and not configured correctly.

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

#37

Post by namelosw »

> It is unclear that the total impact on performance would be significantly negative compared to the typical GraphQL API. Some of the problems also apply to GraphQL, people just need to constrain the query complexity in the end.

But yeah, it would bite Datalog more if not designed well enough, and it's harder to tackle Datalog than to GraphQL.

Other thoughts on this topic:

I love GraphQL but I would love Datalog more if the toolchain is as good as GraphQL.

There's a spectrum on API of simplicity and power -- on the left, there is HTTP/REST which could be seen as a primitive/naive way of describing API it's not consumer-driven at all. On the right there's Datalog which is a powerful way of describing API, it can maximize the flexibility of both the server and the client.

Things like 'map' and 'filter' became well-known to average programmers not very long time ago, though the elite programmers already knew them well half a centry ago. Datalog is definitely a very good idea for API, but I'm afraid it wound't be as popular as GraphQL if Facebook chose this route instead.

That being said, the industry always adopts things in a very passive manner, usually because the current solution is too painful to use, or almost couldn't solve the problem on new problem scale. There's a documentary[0] for GraphQL, the creators had enough of REST, they ended up with inventing GraphQL. It originally was to solving their data fetching problems, in the meantime it would solve others too. Meanwhile, it pushed the common understanding of API for average programmer from left to right on the spectrum. If it's close enough to the right, more and more people would discover Datalog and buzz other people to use it.

Just like type system, it's hard to expect the industry have a deep understanding on the topic itself. Type systems similar to Java dominates the industry for a long time, though ML already existed almost half a centry. Recently, languages like TypeScript tookoff because people need to type existing JavaScript. Then people would discover that the type system they used to is far from enough to describe existing code design. It's like a pandora box, new type operator would came out every release, until people realize there's a spectrum of type system (Lambda Cube[1]), and Dependent T ype would be on the same spot as Datalog on the spectrum.

[0] https://youtu.be/783ccP__No8?t=645 [1] https://en.wikipedia.org/wiki/Lambda_cube

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

#38

Post by imtringued »

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)

Well that's exactly what GraphQL doesn't do. Each GraphQL endpoint is effectively as powerful as a REST endpoint that takes in a JSON object as a parameter. (in other words the QL in the name is a lie) The primary difference is that you can send a batch of GraphQL queries at once and that you can filter attributes that are sent by the endpoint.

I will admit though, that there are a lot of GraphQL implementations that are just a thin wrapper over a database but REST had these for a long time as well.

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

#39

Post by sundbry »

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…

You can handle proper URLs in a SPA if you know what you're doing. It's not something your average frontend dev would pay attention to though, sadly. Server-side "isomorphic" rendering of pages is also possible but a lot more complicated to resolve all the async requests that have to run to render the page.

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

#40

Post by mycall »

triska wrote: post #6
patrickmn wrote: post #3

Earlier quoted context omitted.

What's the best example of modern Datalog?

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.
Post reply on HN