Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JrGQL, a GraphQL alternative

jrgql.github.io

Post reply on HN
Print view View original

41–50 of 59 posts

Re: JrGQL, a GraphQL alternative

#41

Post by alvis »

michaelchisari wrote: post #38
solidsnack9000 wrote: post #26

Earlier quoted context omitted.

At Facebook, GraphQL is used in a such a way that all queries are predeclared -- developers write a collection of queries that represent their client's interface to the backend, and only these queries are used in the live app. This has two positive effects: * It's fairly easy to tell "how the app is using the database" -- queries are not dynamically generated or hidden in code. * The query performance is predictable…

> when you start to think about nested objects you start to warm up to the idea. You do, but any time you try to solve a problem, and your solution ends up being a new language, I think it's worth asking yourself, "Am I overcomplicating this? Can I do this in a simpler way?" And I think you can. I've been toying with an approach I like to call http-etc, which is a simple idea that lets you flag the http (rest) api to…

I cannot agree more on that having a simpler and clearer pattern is perhaps what we need. Solving 90% of GraphQL use cases with 1% of the complexity is a killing point to me.

Re: JrGQL, a GraphQL alternative

#42

Post by KirinDave »

tehbeard wrote: post #37
KirinDave wrote: post #27

Earlier quoted context omitted.

Or move to http2 for services?

Assuming you have control over the api servers. And you have clients that support http2.

Don't (E/A)LBs support http2 now? It's at over 80% client coverage globally, right? Seems pretty safe to IE6 the stragglers and stop worrying about their optimized experience, imo.

Also, http2 push is VERY interesting for application servers.

Re: JrGQL, a GraphQL alternative

#43

Post by KirinDave »

feifan wrote: post #34
KirinDave wrote: post #18

Earlier quoted context omitted.

So let's take the most trivial case. Pretend you can query a Person object with both familyName and personalName. A single GQL query resolver must be able to recognize which field you want and ideally construct the minimum query that meets the requirements. This is much harder than simply recognizing the correct parameters out of the URL, body and queryParams and execute it. While the stakes are low for overfetching…

Very much true. My point though is that I'd expect that complexity to get "built in" at a lower level over time — analogous to how we can submit SQL to a DB server, which has a query planner built-in to figure out how to actually execute the query. App developers don't have to write a SQL query planner.

I've been reading the stuff folks have recommended here. I can explain comonads to a teenager but even I thin that these programming models are pretty intense.

Re: JrGQL, a GraphQL alternative

#44

Post by KirinDave »

CreepGin wrote: post #5
KirinDave wrote: post #2

I still can't quite figure out the value of any of these schemes. Yes, APIs seldom elegantly encode into the set of HTTP verbs and responses that we associate with a "RESTful" design, I grant. And so maybe we can come up with better. But the notion of JrGQL and GQL as query languages means that the servers handling these calls must be query resolvers . Unlike most restful interfaces which tend to devote a single unif…

There are still many gaps the developers need to fill in order to use GraphQL in production. But when implemented correctly, one of the practical benefits is that multiple queries from client to server can be merged into one, thus saving bandwidth and improving performance. a full query model of your domain means an explosive quantity of potential strategies piped through a single endpoint. I agree with this fact. Bu…

> one of the practical benefits is that multiple queries from client to server can be merged into one, thus saving bandwidth and improving performance.

Sure, but if we're doing that by dragging the API implementer over every possible permutation of queries, optimizing whatever you could possibly ask for, I'm not convinced this is LESS work than me shipping BTO API requests.

> I'm sure certain types of projects will benefit more from the pros than cons of GraphQL.

My sneaking suspicion is that it's the kind of projects where their data model is small and isolated and doesn't offer much sharing between queries. Which is great when you can get it.

Re: JrGQL, a GraphQL alternative

#45

Post by KirinDave »

strken wrote: post #17
KirinDave wrote: post #2

I still can't quite figure out the value of any of these schemes. Yes, APIs seldom elegantly encode into the set of HTTP verbs and responses that we associate with a "RESTful" design, I grant. And so maybe we can come up with better. But the notion of JrGQL and GQL as query languages means that the servers handling these calls must be query resolvers . Unlike most restful interfaces which tend to devote a single unif…

As I understand it, the problem GraphQL and related query languages are trying to solve is that in single page web apps and native apps, there's a trade-off between long round trip time on one hand and creating one-off RESTless endpoints that mirror the visual structure of your app on the other. GraphQL allows you to put work into defining resolvers for everything in the hope that it eliminates maybe 90% of your REST…

> Instead of complicating the server to make things a little easier for the client, it simplifies the server by removing knowledge of the client's ui. I'm not sure what you mean by every api endpoint, because graphql should pretty much only have one.

Well I've yet to work with a set of server-side tools that actually deliver on this promise. I really don't like the tools I have.

I'm now attempting to synthesize and optimize SQL queries in python. Messy business. Way more defect-prone.

> DataLoader

I'm a haskell programmer and even I think that programming model is pretty brutal.

Re: JrGQL, a GraphQL alternative

#46

Post by daurnimator »

alvis wrote: post #40
daurnimator wrote: post #36

Earlier quoted context omitted.

The most valuble thing IMO is being able to perform all data fetches in the one database transaction; this means that you get consistent data inside of your application (rather than different divs being out of sync if the page loads while the server is updating content)

This is likely untrue. Unless you fetch data only from one single database, so that you can perform an atomic transition, GraphQL cannot guarantee you to receive the data you want. Technically, a GraphQL server may combine data into a single return from different sources where locking is not possible.

> This is likely untrue. Unless you fetch data only from one single database, so that you can perform an atomic transition

I do! I find it odd that anyone would do anything else...

Re: JrGQL, a GraphQL alternative

#47

Post by gr__or »

Sure, creating a new language is suboptimal. But do I want all my server requests to contain arbitrary Regexes. Hell no!

though I haven't seen a gQL alternative that does a better job, Falcor is close

Re: JrGQL, a GraphQL alternative

#48

Post by lewisl9029 »

alvis wrote: post #39
strken wrote: post #17

Earlier quoted context omitted.

As I understand it, the problem GraphQL and related query languages are trying to solve is that in single page web apps and native apps, there's a trade-off between long round trip time on one hand and creating one-off RESTless endpoints that mirror the visual structure of your app on the other. GraphQL allows you to put work into defining resolvers for everything in the hope that it eliminates maybe 90% of your REST…

As a GraphQL user, hardly I can say it is perfect, but it does solve many current challenges arisen from the surge of mobile use, namely the waste of bandwidth on headers and unused content, as well as latency between requests. From the server point of view, using GraphQL may not sound great since any single tiny update on the schema also implies an update on the single endpoint, rather than just one of many. Until t…

> Meanwhile, I am more concerned about the future of GraphQL as http2 has arrived. With http2, the biggest selling point of reducing latency by using one single endpoint does not sound anymore. Then for the flexibility of limiting the scope of return, you can always specify it on the conventional RESTful API. So there is not much practical benefit. (Oh yes, there are some more goodies like subscription, but let's face it that not many use it) So to make GraphQL more useful, I think it needs a bigger evolution.

GraphQL's most significant latency gain isn't achieved through the use of a single endpoint to minimize parallel requests. As you mentioned, HTTP2 makes this a non-factor in terms of latency. The single endpoint part is only an implementation detail, and most follow it simply by convention.

Rather, GraphQL's major breakthrough in latency reduction is achieved through the use of the graph query language to completely bypass the multiple client-server roundtrip problem for interdependent data (i.e. having to wait for a user request to return the organization id, before being able to send a request to find some property off the organization the user belongs to). HTTP2 isn't able to help at all for this use case.

Re: JrGQL, a GraphQL alternative

#49

Post by jamesgt »

daliwali wrote: post #12

Regardless of technical merit, I don't think it stands any chance of adoption without major users. Specifications and standards are only really valuable as a contract between two or more parties, otherwise they might as well not exist. On the tech side: - RegExps open yourself up to RegExp-based DoS attacks. - The nested/denormalized results anti-pattern seems to be copied from GraphQL. Unless this is intended to be…

Thanks for the feedback, can you expand a bit what you mean by nested/denormalized anti-pattern?
Post reply on HN