well, it is a language for describing interfaces. And a decent one.
What someone uses it for, and how, is entirely different matter.
For a well-thought interface, it will need some language-design thinking. (Of course one can express a well-thought interface in anything, be it REST, SOAP, CORBA..., but in Graphql it is easier and consistent. And yes, graphql is self-documenting.. no swaggering around).
For example, i have made a ~~generic django-orm wrapper, with all the bells-and-whistles i needed - queries, paging and what not (the idea came from graph.cool, reshaped and taken further as "languageness"). And yes, a hand-made ~simple client side as well, none of the usual bloat.
Yeah it is big investment upfront. But after that, work per-object-type is near zero. Before that, the same interface-as-language, was made as REST, and was cumbersome and fragile (there are no types or syntax there, only assumptions).
For a well-thought interface, it will need some language-design thinking. (Of course one can express a well-thought interface in anything, be it REST, SOAP, CORBA..., but in Graphql it is easier and consistent. And yes, graphql is self-documenting.. no swaggering around).
For example, i have made a ~~generic django-orm wrapper, with all the bells-and-whistles i needed - queries, paging and what not (the idea came from graph.cool, reshaped and taken further as "languageness"). And yes, a hand-made ~simple client side as well, none of the usual bloat.
Yeah it is big investment upfront. But after that, work per-object-type is near zero. Before that, the same interface-as-language, was made as REST, and was cumbersome and fragile (there are no types or syntax there, only assumptions).
so.. YMMV.