Ok, here are my two cents regarding GraphQL integration within Openstack and some thoughts around this topic.<br><br>1°/- Openstack SDK should still exist and should be in my humble opinion a critical focus as it allow following benefits for large and medium companies :<br><br>• It provide a common and clean structure for Openstack developments and should be used either by projects or tools willing to integrate Openstack as it will then create some sort of standard. <br><br>For instance, here in my job we have A LOT (More than 10 000 peoples working within around 130 teams) of teams developing over Openstack using the SDK as a common shared base layout.<br>That allow for teams to easily share and co-develop on projects. Those teams are spread around the world and so need to have clean guidelines as it avoid them reinventing the wheel, they’re not stuck with someone else obscure code created by another persons on the other side of the world or within a different timezone.<br>Additionally it streamline our support and debug processes.<br><br>• We should get a common consensus before all projects start to implement it.<br><br>This point is for me the most important one as it will fix flaws we get currently with the rest APIs development within Openstack.<br><br>First it will avoid a fresh developer to be confused by too many options. Honestly, I know we are open etc, but this point really need to be addressed as it is the main issue that I face with Openstack advocacy since many years now.<br><br>Having too many options even if explained within the documentation daunt a lot of people to quickly give a hand with projects.<br><br>For instance I have a workmate that is currently working on an internal tool which ask me how should he implement its project REST interfaces.<br><br>I told him TO NOT use WSME and to stick with what have been done by a major project. Unfortunately he choose to copy what have been done by Octavia which is actually using... WSME...<br><br>GraphQL gives us the opportunity and ability to fix Openstack development inconsistencies by providing and enforcing a clean guideline regarding which library should be used and in which way.<br><br>That would also have the side effect to easy the entry level for a new Openstack developer.<br><br>• New architecture opportunities.<br><br>For sure that will bring new architecture opportunities, but the broker thing is not a good idea as each project should be able to be autonomous.<br><br>I personally don’t like centralized services as it bring SPOF.<br><br>Let’s take the AMQP example. For now most of Openstack deployments use a RabbitMQ or broker like system.<br>Even if each (well at least major vanilla projects) services can (and should) use ZeroMQ.<br>I do myself use RabbitMQ but my last weeks were so much debugging/investigation hell that we now plan to have a serious benchmark and test of ZMQ.<br><br>One thing that I would love to see with GraphQL is a better distributed and traceable model.<br><br>Anyway, I’m glad someone started this discussion as I feel it is a really important topic that would highly help Openstack on more than just interfacing topics.<br><div class="gmail_quote"><div dir="ltr">Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil <<a href="mailto:gdubreui@redhat.com">gdubreui@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="m_-862249484093962862moz-cite-prefix">On 01/05/18 11:31, Flint WALRUS wrote:<br>
</div>
<blockquote type="cite">Yes,
that’s was indeed the sens of my point.<br>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
I was just enforcing it, no worries! ;)</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote type="cite"><br>
Openstack have to provide both endpoints type for a while for
backward compatibility in order to smooth the transition.<br>
<br>
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.<br>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
Shouldn't we have a common consensus before any project start
pushing its own GraphQL wheel?<br>
<br>
Also I wonder how GraphQL could open new architecture avenues for
OpenStack.<br>
For example, would that make sense to also have a GraphQL broker
linking OpenStack services?</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<br>
<blockquote type="cite"><br>
Or alternatively to provide a tool with similar features at least.<br>
<div class="gmail_quote">
<div dir="ltr">Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil <<a href="mailto:gdubreui@redhat.com" target="_blank">gdubreui@redhat.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="m_-862249484093962862m_-9120158338529253301moz-cite-prefix">On
30/04/18 20:16, Flint WALRUS wrote:<br>
</div>
<blockquote type="cite">I would very much second that
question! Indeed it have been one of my own wondering
since many times.<br>
<br>
Of course GraphQL is not intended to replace REST as is
and have to live in parallel </blockquote>
<br>
</div>
<div text="#000000" bgcolor="#FFFFFF"> Effectively a standard
initial architecture is to have GraphQL sitting aside (in
parallel) and wrapping REST and along the way develop
GrapgQL Schema.<br>
<br>
It's seems too early to tell but GraphQL being the next step
in API evolution it might ultimately replace REST.</div>
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote type="cite">but it would likely and highly
accelerate all requests within heavily loaded environments</blockquote>
<br>
</div>
<div text="#000000" bgcolor="#FFFFFF"> +1</div>
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote type="cite">.<br>
<br>
So +1 for this question.<br>
<div class="gmail_quote">
<div dir="ltr">Le lun. 30 avr. 2018 à 05:53, Gilles
Dubreuil <<a href="mailto:gdubreui@redhat.com" target="_blank">gdubreui@redhat.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Remember Boston's Summit presentation [1] about
GraphQL [2] and how it <br>
addresses REST limitations.<br>
I wonder if any project has been thinking about using
GraphQL. I haven't <br>
find any mention or pointers about it.<br>
<br>
GraphQL takes a complete different approach compared
to REST. So we can <br>
finally forget about REST API Description languages <br>
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS
(the hypermedia <br>
approach which doesn't describe how to use it).<br>
<br>
So, once passed the point where 'REST vs GraphQL' is
like comparing SQL <br>
and no-SQL DBMS and therefore have different
applications, there are no <br>
doubt the complexity of most OpenStack projects are
good candidates for <br>
GraphQL.<br>
<br>
Besides topics such as efficiency, decoupling, no
version management <br>
need there many other powerful features such as API
Schema out of the <br>
box and better automation down that track.<br>
<br>
It looks like the dream of a conduit between API
services and consumers <br>
might have finally come true so we could move-on an
worry about other <br>
things.<br>
<br>
So has anyone already starting looking into it?<br>
<br>
[1] <br>
<a href="https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql" rel="noreferrer" target="_blank">https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql</a><br>
[2] <a href="http://graphql.org" rel="noreferrer" target="_blank">http://graphql.org</a><br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
</blockquote>
<br>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<pre class="m_-862249484093962862m_-9120158338529253301moz-signature" cols="72">--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: <a class="m_-862249484093962862m_-9120158338529253301moz-txt-link-abbreviated" href="mailto:gilles@redhat.com" target="_blank">gilles@redhat.com</a>
GitHub/IRC: gildub
Mobile: +61 400 894 219
</pre>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre class="m_-862249484093962862moz-signature" cols="72">--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: <a class="m_-862249484093962862moz-txt-link-abbreviated" href="mailto:gilles@redhat.com" target="_blank">gilles@redhat.com</a>
GitHub/IRC: gildub
Mobile: +61 400 894 219
</pre>
</div></blockquote></div>