On 01/05/18 11:31, Flint WALRUS wrote:
Yes, that’s was indeed the sens of my point.
I was just enforcing it, no worries! ;)
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.
Shouldn't we have a common consensus before any project start pushing
its own GraphQL wheel?
Also I wonder how GraphQL could open new architecture avenues for OpenStack.
For example, would that make sense to also have a GraphQL broker linking
OpenStack services?
Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil <gdubr...@redhat.com
<mailto: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 <mailto: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://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 <mailto:gil...@redhat.com>
GitHub/IRC: gildub
Mobile: +61 400 894 219
--
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
