<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>I fixed the GraphQL typo (my mistake) in $subject to help with
      future ML searches.</p>
    <p>Please see inline too.<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 02/05/18 07:37, Flint WALRUS wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAG+53ubhXdDWR-5nhH_peiNk_-t9z0N4ZJgDuomZ0ag+vUQm6Q@mail.gmail.com">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>
    </blockquote>
    <br>
    I'm assuming you're talking about the Python SDK (Shade) which would
    make sense because it's the "lingua franca" of all projects.<br>
    <br>
    Nevertheless, for any SDKs/Languages, if adopted then GraphQL is
    likely to replace its REST SDK on the long run. GraphQL is a DSL
    bypassing a SDK need which get replaced with GraphQL client library.
    Basically the change, not a rewrite, is inevitable. But I insist on
    "the long run" part, initially both in parallel one wrapping the
    other, then progressively the REST content moving across to GraphQL.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAG+53ubhXdDWR-5nhH_peiNk_-t9z0N4ZJgDuomZ0ag+vUQm6Q@mail.gmail.com"><br>
      • We should get a common consensus before all projects start to
      implement it.<br>
    </blockquote>
    <br>
    <br>
    This is going to be raised during the API SIG weekly meeting later
    this week.<br>
    API developers (at least one) from every project are strongly
    welcomed to participate.<br>
    I suppose it makes sense for the API SIG to be the place to discuss
    it, at least initially. <br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAG+53ubhXdDWR-5nhH_peiNk_-t9z0N4ZJgDuomZ0ag+vUQm6Q@mail.gmail.com"><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>
    </blockquote>
    <br>
    I couldn't agree more!<br>
    <br>
    <blockquote type="cite"
cite="mid:CAG+53ubhXdDWR-5nhH_peiNk_-t9z0N4ZJgDuomZ0ag+vUQm6Q@mail.gmail.com"><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>
    </blockquote>
    <br>
    Exactly and the term broker I used is far from ideal,  I meant it in
    the context of a broker pattern providing distributed API service.
    GraphQL has "stiching" capabilities allowing to forward request to
    diverse GraphQL service, kind of a proxy, ideally such service to be
    distributed itself. <br>
     <br>
    The idea behind is a GraphQL proxy offering a single point of entry
    for OpenStack entire stack and of course leaving complete autonomy
    to the all services.<br>
    <br>
<a class="moz-txt-link-freetext" href="https://blog.graph.cool/graphql-schema-stitching-explained-schema-delegation-4c6caf468405">https://blog.graph.cool/graphql-schema-stitching-explained-schema-delegation-4c6caf468405</a><br>
    <br>
    <blockquote type="cite"
cite="mid:CAG+53ubhXdDWR-5nhH_peiNk_-t9z0N4ZJgDuomZ0ag+vUQm6Q@mail.gmail.com">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
                            moz-do-not-send="true">https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql</a><br>
                          [2] <a href="http://graphql.org"
                            rel="noreferrer" target="_blank"
                            moz-do-not-send="true">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"
                            moz-do-not-send="true">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"
                            moz-do-not-send="true">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                        </blockquote>
                      </div>
                    </blockquote>
                  </div>
                </blockquote>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>