7 ms·

JrGQL, a GraphQL alternative

75 points by jamesgt 9y ago

nateguchi 9y ago
Is the fact that GraphQL is typed really a negative?
- dsun180 9y ago
  Thought the same. Strict typing allows many optimisations and compressions. Without strict types most of graphQL has no benefits anymore.
  - CreepGin 9y ago
    I second this. Currently with the right tooling and IDE extension, I can get autocompletion and various compile-time checks with GraphQL schemas.
- yen223 9y ago
  Just knowing which fields are nullable, that's already a surprisingly huge productivity boost.
- jamesgt 9y ago
  I'm not saying it is negative. Probably I should not color red the background in the table. I just wanted to point out where jrGQL is different from others.
cdevs 9y ago
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.
SirensOfTitan 9y ago
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 9y ago
  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.
daliwali 9y ago
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 9y ago
  Thanks for the feedback, can you expand a bit what you mean by nested/denormalized anti-pattern?
KirinDave 9y ago
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.
- deegles 9y ago
  I think you answered your own question... GraphQL and similar are meant to push complexity to the endpoint partly in order to not tax resource-constrained clients. If that's part of your requirements then it's a great fit, otherwise your points are valid.
  - KirinDave 9y ago
    In a more perfect world, it'd make sense. Mutations in particular make lots of sense because it narrows the scope of any required transactional semantics. But the fact that I've only seen one implementation correctly implement the query semantics worries me deeply. At first I assumed I was using bad libraries! But soon I realized that lots of devs were simply shipping significantly less efficient servers to production.
MentallyRetired 9y ago
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 9y ago
  Thanks for the feedback. https://github.com/jrgql/jrgql.github.io/issues/3 https://github.com/jrgql/jrgql.github.io/issues/3
rockwotj 9y ago
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 9y ago
  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
swlkr 9y ago
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-to-rest 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.
wereHamster 9y ago
In what world is "strictly typed: No" an advantage?
- jamesgt 9y ago
  Where you want to store not predefined keys in your objects.
  - wereHamster 9y ago
    That's called a map. Most (all?) strongly typed languages have a map type in their stdlib.
    - jamesgt 9y ago
      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?
gr__or 9y ago
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 9y ago
  Thanks for the feedback. I've seen Falcor once, but will check it again. It should probably be added to the comparison table.

75 points by jamesgt 9y ago

nateguchi 9y ago

Is the fact that GraphQL is typed really a negative?

dsun180 9y ago
Thought the same. Strict typing allows many optimisations and compressions. Without strict types most of graphQL has no benefits anymore.
- CreepGin 9y ago
  I second this. Currently with the right tooling and IDE extension, I can get autocompletion and various compile-time checks with GraphQL schemas.
yen223 9y ago
Just knowing which fields are nullable, that's already a surprisingly huge productivity boost.
jamesgt 9y ago
I'm not saying it is negative. Probably I should not color red the background in the table. I just wanted to point out where jrGQL is different from others.

cdevs 9y ago

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.

SirensOfTitan 9y ago

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 9y ago
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.

daliwali 9y ago

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 9y ago
Thanks for the feedback, can you expand a bit what you mean by nested/denormalized anti-pattern?

KirinDave 9y ago

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.

deegles 9y ago
I think you answered your own question... GraphQL and similar are meant to push complexity to the endpoint partly in order to not tax resource-constrained clients. If that's part of your requirements then it's a great fit, otherwise your points are valid.
- KirinDave 9y ago
  In a more perfect world, it'd make sense. Mutations in particular make lots of sense because it narrows the scope of any required transactional semantics. But the fact that I've only seen one implementation correctly implement the query semantics worries me deeply. At first I assumed I was using bad libraries! But soon I realized that lots of devs were simply shipping significantly less efficient servers to production.

MentallyRetired 9y ago

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 9y ago
Thanks for the feedback. https://github.com/jrgql/jrgql.github.io/issues/3 https://github.com/jrgql/jrgql.github.io/issues/3

rockwotj 9y ago

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 9y ago
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

swlkr 9y ago

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

wereHamster 9y ago

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

jamesgt 9y ago
Where you want to store not predefined keys in your objects.
- wereHamster 9y ago
  That's called a map. Most (all?) strongly typed languages have a map type in their stdlib.
  - jamesgt 9y ago
    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?

gr__or 9y ago

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 9y ago
Thanks for the feedback. I've seen Falcor once, but will check it again. It should probably be added to the comparison table.