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

21–30 of 59 posts

Re: JrGQL, a GraphQL alternative

#21

Post by pithic »

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…

> 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 uniform interface per endpoint with only minor modifications, a full query model of your domain means an explosive quantity of potential strategies piped through a single endpoint.

GQL does seem to encourage, if not assume, a type-theoretical graph datastore as the backend. (Who couldn't whip such a thing together, if it were lacking?)

But it does not require one. This point may be lost in the tutorial and examples shown on graphql.org. There is no reason one could not map a basic GQL service onto an existing set of REST endpoints, with each one a type, and the return of their fields controlled by the request.

Re: JrGQL, a GraphQL alternative

#22

Post by swlkr »

In my limited experience implementing a GraphQL server with node.js at work for a smaller app, it adds quite a bit of complexity to getting data out of a relational database.

After implementing GQL, I found this very old slide show on REST and it happened to solve my complexity problems. https://www.slideshare.net/mobile/landlessness/teach-a-dog-t...

GQL and this alternative have their place and they solve problems for very large teams of (like the teams at Facebook), but for smaller teams and smaller apps, I'm not sure it's the right solution to REST's "join" problem.

Re: JrGQL, a GraphQL alternative

#23

Post by KirinDave »

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

> 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 uniform interface per endpoint with only minor modifications, a full query model of your domain means an explosive quantity of potential strategies piped through a single endpoint. GQL does seem to encourage, if not assume, a type-theore…

> There is no reason one could not map a basic GQL service onto an existing set of REST endpoints, with each one a type, and the return of their fields controlled by the request.

I know you meant this to be rhetorical but unless this added some fundamental features (e.g., abstracting a distributed transaction negotiation) besides a new awkward interface I think I'd lose my mind writing GQL proxies over all my existing services.

Why just add a layer of waste and latency, along with a whole new intermediate serialization? Seems like make work. Just to adopt a technology for no real reason.

Re: JrGQL, a GraphQL alternative

#24

Post by strken »

KirinDave wrote: post #23
pithic wrote: post #21

Earlier quoted context omitted.

> 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 uniform interface per endpoint with only minor modifications, a full query model of your domain means an explosive quantity of potential strategies piped through a single endpoint. GQL does seem to encourage, if not assume, a type-theore…

> There is no reason one could not map a basic GQL service onto an existing set of REST endpoints, with each one a type, and the return of their fields controlled by the request. I know you meant this to be rhetorical but unless this added some fundamental features (e.g., abstracting a distributed transaction negotiation) besides a new awkward interface I think I'd lose my mind writing GQL proxies over all my existin…

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 rendering everything on the server, create an endpoint for each page, or implement some way of querying embedded resources.

GraphQL acting as an intermediary for multiple REST apis is one way of doing the latter.

Re: JrGQL, a GraphQL alternative

#25

Post by dustingetz »

lewisl9029 wrote: post #13
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…

Client UX is king for a large majority of user facing applications. And that's where client-centric query mechanisms like GraphQL/Falcor/Om.next make the most sense. The point is exactly to push data fetching complexity from the Client to the API server. And that's generally a worthwhile tradeoff for these applications because you can deal with server complexity by throwing more money at your API server cluster, but…

you can run the javascript client in the server, that is what http://hyperfiddle.net/ does

For example, server side rendering. Though Hyperfiddle is a bit more sophisticated than that.

Re: JrGQL, a GraphQL alternative

#26

Post by solidsnack9000 »

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 and controllable in the same way as a stored procedure approach to database access -- but without actually requiring a DBA to load/unload procedure definitions.

One might argue that these benefits could be obtained without codifying a new query language...but when you start to think about nested objects you start to warm up to the idea.

Re: JrGQL, a GraphQL alternative

#27

Post by KirinDave »

strken wrote: post #24
KirinDave wrote: post #23

Earlier quoted context omitted.

> There is no reason one could not map a basic GQL service onto an existing set of REST endpoints, with each one a type, and the return of their fields controlled by the request. I know you meant this to be rhetorical but unless this added some fundamental features (e.g., abstracting a distributed transaction negotiation) besides a new awkward interface I think I'd lose my mind writing GQL proxies over all my existin…

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?

Re: JrGQL, a GraphQL alternative

#29

Post by intellix »

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 like to think of it like this: If you over fetch, you throw it away at the server and not after sending it to the client. You can wrap a standard REST API and it'll still be more optimal.

We've been using REST and slowly adding hacks to stop sending so much data. We have 2x API calls that used to be 1mb each and now they're something like 5kb with GQL.

Re: JrGQL, a GraphQL alternative

#30

Post by thejosh »

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 queries very well via pattern matching, and I also know the queries ahead of time. In future I would want to lock these down to certain queries.

I'm very impressed by GQL, after having to deal with crappy APIs in the past. JSONAPI was almost perfect to me (working with Ember), but the fact there was no bulk submit was very shity to me.

Post reply on HN