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/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
