51–59 of 59 posts
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.
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
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
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
Is the fact that GraphQL is typed really a negative?
I just wanted to point out where jrGQL is different from others.
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 com…
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.
Earlier quoted context omitted.
This is likely untrue. Unless you fetch data only from one single database, so that you can perform an atomic transition, GraphQL cannot guarantee you to receive the data you want. Technically, a GraphQL server may combine data into a single return from different sources where locking is not possible.
> This is likely untrue. Unless you fetch data only from one single database, so that you can perform an atomic transition I do! I find it odd that anyone would do anything else...
In microservices-driven-architrctures you often have to appeal to multiple services to service a request.
Earlier quoted context omitted.
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…
> when you start to think about nested objects you start to warm up to the idea. You do, but any time you try to solve a problem, and your solution ends up being a new language, I think it's worth asking yourself, "Am I overcomplicating this? Can I do this in a simpler way?" And I think you can. I've been toying with an approach I like to call http-etc, which is a simple idea that lets you flag the http (rest) api to…
Earlier quoted context omitted.
Where you want to store not predefined keys in your objects.
That's called a map. Most (all?) strongly typed languages have a map type in their stdlib.