
JrGQL, a GraphQL alternative - jamesgt
https://jrgql.github.io/
======
KirinDave
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.

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

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

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

------
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...](https://www.slideshare.net/mobile/landlessness/teach-a-dog-to-rest)

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.

------
SirensOfTitan
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 } } ```

~~~
jamesgt
Thanks for the feedback.

I see now that regex may be an overkill, the main intent was to support keys
that are not predefined. It is easy to imagine a data set where a lot of keys
can exist with the same prefix: { "text-decoration": "underline", "text-
decoration-color": "red", "text-align": "center" } For this situation it may
be useful to query all the keys with prefix "text-", without exactly knowing
what are the possible keys. Since document databases and JavaScript are
popular, we should open up the strict typing. Clients may have the right to
store arbitrary metadata on their objects. In GraphQL you have this option,
just add a metadata key as string and you can dump anything there, but this
way you lose the option to filter on this. That exact missing feature inspired
jrGQL.

1\. Yes, it is not a new language, since it is always a valid JSON. This is
useful since every validator, syntax highlighter already knows it. GraphQL
created a new language just because they not considered to reuse an existing
one. You can say that jrGQL still needs parsing on top of JSON, but every
query should be validated on the server side and that needs parsing too. Also
we can call regex evaluation as parsing, but this is just a more by a
substring() call than simple equality check to filter the result set.

2\. Coloring is definitely a mistake, I'll fix it. I did not want to say that
others are bad in anything. Man, those are production ready quality and this
thing is just a concept with only a reference implementation. I just wanted to
show where jrGQL is different from others.

3\. This is about tastes, I should add that for _me_ it is more readable. I
don't like GetAllTheThingsQuery stuff, since it is defined by an other party,
if you need that it is an other endpoint and you get what you were meant to
get, but no control. With jrGQL you always get what you requested, so it is
not WYSIWYG, but WYRIWYG.

------
nateguchi
Is the fact that GraphQL is typed really a negative?

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

~~~
CreepGin
I second this. Currently with the right tooling and IDE extension, I can get
autocompletion and various compile-time checks with GraphQL schemas.

------
rockwotj
To quote the famous:

Some people, when confronted with a problem, think “I know, I'll use regular
expressions.” Now they have two problems.

Source:
[http://regex.info/blog/2006-09-15/247](http://regex.info/blog/2006-09-15/247)

~~~
jamesgt
We get recognition and/or money for solving problems ;)

Although you and almost everybody else was pointing out regex as a possible
problem or at least as an unnecessary complexity. I plan to handle this:
[https://github.com/jrgql/jrgql.github.io/issues/2](https://github.com/jrgql/jrgql.github.io/issues/2)

------
MentallyRetired
Bless your little heart. graphQL is a pain in the butt.

Now just marry the mutations to the GET/POST/PUT/DELETE operations of REST and
I'll be smitten. No parent +/\- node needed, and there are already a ton of
REST libs out there.

~~~
jamesgt
Thanks for the feedback.
[https://github.com/jrgql/jrgql.github.io/issues/3](https://github.com/jrgql/jrgql.github.io/issues/3)

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

~~~
jamesgt
Thanks for the feedback. I've seen Falcor once, but will check it again. It
should probably be added to the comparison table.

------
wereHamster
In what world is "strictly typed: No" an advantage?

~~~
jamesgt
Where you want to store not predefined keys in your objects.

~~~
wereHamster
That's called a map. Most (all?) strongly typed languages have a map type in
their stdlib.

~~~
jamesgt
Ok, yes, I agree, but can you please point out how you can store and
query/filter on map contents with not predefined keys in GraphQL?

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

~~~
jamesgt
Thanks for the feedback, can you expand a bit what you mean by
nested/denormalized anti-pattern?

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

