Decouple DSL from GraphQL::Client logic #114
Description
Is your feature request related to a problem? Please describe.
GraphQL::Client has been abandoned, and big corps are flying away en-mass, due to its clear and unsolvable limitations.
Graphlient is a great idea. Wouldn't it be better to split this project into two parts: transpilation/converter from ruby blocks to GQL on one hand, and validation on the other hand?
Describe the solution you'd like
I would very much like that I could have a specialized transpiler that converts the ruby blocks into GQL, provided that it can be enriched with all the GraphQL language (i.e. directives, fragments).
Then, you may opt in for automated validations, or you would just launch the request for the server to do this part of the job. A raw HTTP request for GraphQL is just 3 or 4 properties of a JSON object (i.e. query, variables, operation_name).
Describe alternatives you've considered
The alternative I was considering is to implement the transpiller myself in a separated gem that is uniquely dedicated to this end.
Additional context
GraphQL::Client has serious drawbacks. One of which is the impossibility to create a custom query that is built up out of fragments. Each fragment needs to be declared into a constant. This is just non-scalable at all. Moreover, while fragments can be used to simplify and tidily organize your queries, GraphQL::Client assumes that you would want to have fragments only to protect access between components. That's not the only purpose of fragments. Their classes built on the fly become completely inaccessible when you use fragments. It is just nonsense.
What you would want to do is to just create a neat client implementation of your GraphQL. Instead, you see yourself trying to work around these very limitations.
Also, when there is a validation error, Graphlient doesn't explain the problem. It just throws an error, and it is your job to figure it out.