Open Stack

On 01/05/18 07:21, Matt Riedemann wrote:
> On 4/29/2018 10:53 PM, Gilles Dubreuil wrote:
>> Remember Boston's Summit presentation [1] about GraphQL [2] 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?
>>
>> [1] 
>> https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql 
>>
>> [2] 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:
>
> https://dague.net/2017/12/11/rest-api-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 [1]). 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.

Cheers

[1] http://graphql.org/code/