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

11–20 of 59 posts

Re: JrGQL, a GraphQL alternative

#11

Post by feifan »

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…

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

Re: JrGQL, a GraphQL alternative

#12

Post by daliwali »

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 a faithful reproduction, don't copy mistakes.

Re: JrGQL, a GraphQL alternative

#13

Post by lewisl9029 »

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't force your users to upgrade to more performant clients.

Of course, server-side overfetching is a problem that can drastically limit the scalability of your system by overloading the components you can't as easily scale by spinning up more machines (i.e. most databases). Naive implementations of GraphQL on the server can be ridiculously chatty and require multiple server-db roundtrips to resolve even the simplest of queries, which can arguably be an even nastier problem than dealing with multiple client-server roundtrips with a RESTful API.

This is why non-trivial GraphQL servers generally use some kind of resolver batching/caching layer (Facebook provides a library called DataLoader to facilitate this: https://github.com/facebook/dataloader) or a query planner at your root resolver (like Join Monster: https://github.com/stems/join-monster).

Neither of these approaches is trivial to implement, but then again, doing efficient data fetching on the client against a RESTful API is just as difficult, if not more so. Efficient data-fetching is just a very difficult problem, and involves essential complexity that needs to live somewhere. At the end of the day it's up to you if you want to deal with that complexity in your clients (using a traditional RESTful API) or on your API servers (using a query mechanism like GraphQL).

Re: JrGQL, a GraphQL alternative

#14

Post by reggieband »

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'm not 100% sold on GraphQL but the teams I work with are moving towards it. It does help a bit with micro-service architectures since you'd be writing some API interface to abstract potentially dozens of services anyway. After the pain of writing all of the necessary bindings/schemas/models or whatever they all are it is convenient at least on the calling side. The web GUI for testing out schema's comes in very handy.

The pain I've felt is with API versioning. Someone set a type for a parameter wrong, it was a union between int and string but the original implementation was only typed for int. Since it was sent out to production that becomes too risky to change since the call will fail if the param type is wrong, even though the underlying JS would have handled ints and strings just fine.

Overall it is a pretty neutral technology for me. The benefits and determents seem to balance just enough that I'm not going to pick that battle to fight against it. So while I agree it doesn't add as much value as the hype might suggest, it also doesn't detract enough to worry about.

Re: JrGQL, a GraphQL alternative

#15

Post by chung705 »

reggieband wrote: post #14
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'm not 100% sold on GraphQL but the teams I work with are moving towards it. It does help a bit with micro-service architectures since you'd be writing some API interface to abstract potentially dozens of services anyway. After the pain of writing all of the necessary bindings/schemas/models or whatever they all are it is convenient at least on the calling side. The web GUI for testing out schema's comes in very han…

I guess in terms of deprecation, it is not a unique characteristic to GraphQL, it happens to RESTful APIs as well.

Re: JrGQL, a GraphQL alternative

#16

Post by lewisl9029 »

reggieband wrote: post #14
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'm not 100% sold on GraphQL but the teams I work with are moving towards it. It does help a bit with micro-service architectures since you'd be writing some API interface to abstract potentially dozens of services anyway. After the pain of writing all of the necessary bindings/schemas/models or whatever they all are it is convenient at least on the calling side. The web GUI for testing out schema's comes in very han…

The versioning problem can usually be resolved fairly elegantly by versioning on a field-by-field level, i.e. adding a new field called x-v2 and serve it alongside x without removing the original. You can add some kind of a deprecation warning to x to dissuade new clients from using it.

With this approach you can end up with a somewhat noisy schema, but for public APIs it's usually worthwhile to just keep the old versions forever to avoid breakage. For private APIs, with good tracking, you can find out when the original field stops getting requested, and clean up your schema then with relatively little risk.

Re: JrGQL, a GraphQL alternative

#17

Post by strken »

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 RESTless routes. 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.

Regarding nodejs and overfetching, the canonical solution is Facebook's DataLoader library. I think it might even be in the docs somewhere.

Regarding jrGQL, I'm not sure the use case is the same. They look like different tools for different problems, but I'd be interested in hearing more about what problem it solves.

Re: JrGQL, a GraphQL alternative

#18

Post by KirinDave »

feifan wrote: post #11
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…

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 in this case (odds are the DB doesn't notice and maybe it's not a problem for your network link), as a general problem (in particular when fields have subfields) this gets frustrating very quickly.

My concern is not that this is bad for clients. It makes a ton of sense for clients. It's just much harder for servers to schedule optimal queries. Suddenly you're not only managing unreliable resources and minimizing latencies you don't own, you're also a compiler or interpreter for a language with more than one valid query.

For some types of backing stores it may not matter (ECKRV's such as Dynamo, for example). For others it may matter a lot (Postgres). And I think a lot of server owners ship backends that maybe do 2x more querying than they have to, given the "best practices" and examples I see online for the NodeJs bindings.

I've heard the Erlang bindings are very good. I haven't tried them yet, as Erlang isn't very high on my list of tools to use these days (not because it's bad). Maybe they have a silver bullet.

Post reply on HN