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 <gdubr...@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 <gdubr...@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-requ...@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: gil...@redhat.com > GitHub/IRC: gildub > Mobile: +61 400 894 219 > > >
__________________________________________________________________________ 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