[openstack-dev] [api] REST limitations and GraghGL inception?
gdubreui at redhat.com
Tue May 1 02:36:54 UTC 2018
On 01/05/18 07:21, Matt Riedemann wrote:
> On 4/29/2018 10:53 PM, Gilles Dubreuil wrote:
>> Remember Boston's Summit presentation  about GraphQL  and how
>> it addresses REST limitations.
>> I wonder if any project has been thinking about using GraphQL. I
>> haven't find any mention or pointers about it.
>> GraphQL takes a complete different approach compared to REST. So we
>> can finally forget about REST API Description languages
>> (OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
>> approach which doesn't describe how to use it).
>> So, once passed the point where 'REST vs GraphQL' is like comparing
>> SQL and no-SQL DBMS and therefore have different applications, there
>> are no doubt the complexity of most OpenStack projects are good
>> candidates for GraphQL.
>> Besides topics such as efficiency, decoupling, no version management
>> need there many other powerful features such as API Schema out of the
>> box and better automation down that track.
>> It looks like the dream of a conduit between API services and
>> consumers might have finally come true so we could move-on an worry
>> about other things.
>> So has anyone already starting looking into it?
>>  http://graphql.org
> Not to speak for him, but Sean Dague had a blog post about REST API
> microversions in OpenStack and there is a Q&A bit at the bottom about
> GraphQL replacing the need for microversions:
> Since I don't expect Sean to magically appear to reply to this thread,
> I thought I'd pass this along.
Thanks Matt for the link.
During Denver's PTG we effectively discovered consumers tend to use 3rd
party SDK and we also discovered that, ironically, nobody - besides Sean
;) - has the bandwidth to work full time on SDK either. That was and
still is the driver for more automation and therefore for having
projects to produce an API Schema.
Once aspect is about GraphQL being a descriptive language. It allow to
decouple entirely consumers from producers. So instead of SDK, consumers
rely on GraphQL client library (which are standardized ). The focus
becomes the data and not how to transfer the data.
Effectively, services make their data available through a Schema and
clients request a tree of data against it. Sure, at the end of the day,
it's still a HTTP conversation taking place and returning a JSON
structure (when not up/down loading a file or so). The big difference
(among other things) is one and only one transaction is used.
The second aspect is about automation which can take place because the
Schema is provided up-front, it's the Graph part.
In the Q&A, Sean said SDK "build their object models", yes that's true
with GraphQL we have "fat clients" but as we've also seen the SDK is
replaced with a GraphQL client., cutting the "man in the middle" off!
As per the rest of the Answer, it seems to me there are other aspects to
be looked at it from different angles.
More information about the OpenStack-dev