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

31–40 of 59 posts

Re: JrGQL, a GraphQL alternative

#31

Post by KirinDave »

thejosh wrote: post #30
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…

I use Elixir and Absinthe, and was very skeptical as well until the past month about GQL. I'm now completely sold, for a JS powered app, using Preact and Apollo-client makes working with the backend incredibly easy, and realtime via subscriptions works very well. I've used it to build a couple of large apps, and am seeing very good results, and much easier to build something in the frontend. The backend handles these…

I suspect I would like it more if I wasn't stitching microservices that might also need client interfaces together.

Gql buys me absolutely nothing at all having microservices connect.

Re: JrGQL, a GraphQL alternative

#32

Post by KirinDave »

solidsnack9000 wrote: post #26
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…

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…

This makes a LOT more sense. The compiler part is what keeps hanging me up.

Re: JrGQL, a GraphQL alternative

#34

Post by feifan »

KirinDave wrote: post #18
feifan wrote: post #11

Earlier quoted context omitted.

Why does "a single endpoint" matter? It seems like the endpoint essentially becomes an implementation detail. True, resolvers can be complicated. But would you bet against improvements to tooling/languages/frameworks making it palatable? IMO GQL's value is compelling enough for something analogous to Rails (something that abstracts away much of the mechanics through convention) to emerge

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.

Re: JrGQL, a GraphQL alternative

#35

Post by sAbakumoff »

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…

>> The popular NodeJS bindings tend to cause huge overfetching because each field tends to have a unique resolver but there is no rule about combining them.

I don't have any experience with NodeJS+GQL but used Golang+GQL a lot. Typically a resolver of a field simply returns the property of a structure that is returned by the parent field, that's it. The only thing is the parent field should unboxed from the interface{} type.

Re: JrGQL, a GraphQL alternative

#36

Post by daurnimator »

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…

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)

Re: JrGQL, a GraphQL alternative

#37

Post by tehbeard »

KirinDave wrote: post #27
strken wrote: post #24

Earlier quoted context omitted.

It depends on what your UI is. If your page displays information that can be loaded with a few concurrent calls to a single RESTful endpoint each, then by all means stick with that. On the other hand, if your page loads information from ten different endpoints across three different services, and some calls depend on the results of previous calls, then you have four options: take a massive performance hit, go back to…

Or move to http2 for services?

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

Re: JrGQL, a GraphQL alternative

#38

Post by michaelchisari »

solidsnack9000 wrote: post #26
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…

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 say, "Give me this data, but also give me the graph associated with this data."

For instance, if I want an article, I would do:

  /api/0.1/article/z098d0s8dga
That would give me information about the article with the slug or internal id of z098d0s8dga.

But if I want an article, plus the comments associated with it, and information about the users that posted those comments, I can do:

  /api/0.1/article/z098d0s8dga+
You have two routes that are very similar but work in completely different ways. One gets specific information, the other returns the graph from a specific starting point.

And this is handled completely with your server-side api design. You have your singular route to one function, and you have your "etc" route to another function. Synchronizing the shape of the data requested/returned between server and client is still handled manually, but it seems to me this pattern solves 90% of GraphQL use cases with 1% of the complexity of GraphQL. It isn't tied to any specific language or codebase on the server-side. It doesn't require a big client-side library be added to your project. It's just a simple pattern.

Re: JrGQL, a GraphQL alternative

#39

Post by alvis »

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…

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 there is an implementation of dynamic modularization, maintaining the integrality of a service is a constant pain.

Fairly enough, I think the tradeoff is balanced. GraphQL solves problems on the client side and yet it creates problems on the server side.

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.

Re: JrGQL, a GraphQL alternative

#40

Post by alvis »

daurnimator wrote: post #36
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…

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