Open Stack

Yes, that’s was indeed the sens of my point.

Openstack have to provide both endpoints type for a while for backward
compatibility in order to smooth the transition.

For instance, that would be a good idea to contact postman devteam once
GraphQL will start to be integrated as it will allow a lot of ops to keep
their day to day tools by just having to convert their existing collections
of handful requests.

Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil <gdubreui at redhat.com> a écrit :

>
>
> On 30/04/18 20:16, Flint WALRUS wrote:
>
> I would very much second that question! Indeed it have been one of my own
> wondering since many times.
>
> Of course GraphQL is not intended to replace REST as is and have to live
> in parallel
>
>
> Effectively a standard initial architecture is to have GraphQL sitting
> aside (in parallel) and wrapping REST and along the way develop GrapgQL
> Schema.
>
> It's seems too early to tell but GraphQL being the next step in API
> evolution it might ultimately replace REST.
>
>
> but it would likely and highly accelerate all requests within heavily
> loaded environments
>
>
> +1
>
>
> .
>
> So +1 for this question.
> Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil <gdubreui at redhat.com> a
> écrit :
>
>> Hi,
>>
>> 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
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> --
> Gilles Dubreuil
> Senior Software Engineer - Red Hat - Openstack DFG Integration
> Email: gilles at redhat.com
> GitHub/IRC: gildub
> Mobile: +61 400 894 219
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180501/96ccc95b/attachment.html>