JrGQL, a GraphQL alternative

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

I've used Python, Ruby, Node (in ts and js) and Haskell to service GQL queries and in all cases it's not trivial.

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. The pooular Python bindings (graphene) let you merge this, but the programming model to handle the arguments and sub-arguments is very frustrating as in different places, different soirces of logic will government what gets fetched (sub objects use SqlAlchemy, but outer objects with ANY sorry of query logic need to be custom). Ruby's bindings are the same.

Haskell's popular solution let's you cobble a responder from a proof of concept, and it leads to optimal query scheduling. Still not the best: it's by no means complete and requires quite a lot of work to set up.

These GQL systems push a huge burden onto every api endpoint with the proposed trade-off: "Well now the client has an easier time." Even if that's true, now the backend needs to be much, much smarter than before to give a marginally better interface for clients.

I'm still very skeptical of this whole concept.

Is the fact that GraphQL is typed really a negative?

Thought the same. Strict typing allows many optimisations and compressions. Without strict types most of graphQL has no benefits anymore.

I'm against any new startup looking to jump on the graphQL band wagon, Facebook did it so no one asked questions as if there would never be idea to improve. Just make a jsonrpc endpooint allows an array of your other API request, done, mixed request. The first time I heard a company switching to it was the complain a iOS dev couldn't make smaller request and request all info at once because he was lazy. If he was lazy then he will be lazy again, make him paginate 100s of photos to a few at a time, done, move on. I think the best idea is making the client request what they expect back so you can add on but that can be forced in any API method.

A couple thoughts here.

First off, what are the advantages of regex queries here? One of the major advantages of GraphQL alongside libraries like Relay or Apollo is that there are strict, easy to understand data requirements that are tightly coupled to view logic. I know my server API, why would I want something like this? Especially in considering the regex keys incur a non-trivial performance penalty.

This page comes across misleading or disingenuous at worst:

1. "JrGQL" is listed as a non "new language" even though GraphQL's spec was published before it came out, and has been in use at Facebook since 2012. I'd imagine this is because jrGQL uses JSON. It still requires parsing on top of JSON. I don't know why the author thinks this counts as a non-new language.

2. All of the jrGQL "features" listed in green and almost all of the competitors in red or yellow? The page does nothing to claim why strict typing is a bad thing.

3. jrGQL is touted as more readable without any explanation as to why. I personally find it way more unreadable, as graphQL comes across largely intuitive to query even without knowledge of it (building performant gql servers is another story). For example, can author really claim that something like:

```

{ "// JSON RegExp Graph Query Language": "", "name": "jrGQL", "?[filter]": "", "search?": ".values$" }

// is more readable than: query GetAllTheThingsQuery { people(name: "GQL", search: "Smith", first: 5) { name } } ```