<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 11/10/18 00:18, Jeremy Stanley
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20181010131849.ey5yf3zxjtevtnae@yuggoth.org">
<pre wrap="">On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 09/10/18 23:58, Jeremy Stanley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
[...]
</pre>
<blockquote type="cite">
<pre wrap="">It seems to me that a major goal of openstacksdk is to hide
differences between clouds from the user. If the user is meant
to use a GraphQL library themselves, we lose this and the user
needs to figure it out themselves. Did I understand that
correctly?
</pre>
</blockquote>
<pre wrap="">This is especially useful where the SDK implements business
logic for common operations like "if the user requested A and
the cloud supports features B+C+D then use those to fulfil the
request, otherwise fall back to using features E+F".
</pre>
</blockquote>
<pre wrap="">
The features offered to the user don't have to change, it's just a
different architecture.
The user doesn't have to deal with a GraphQL library, only the
client applications (consuming OpenStack APIs). And there are also
UI tools such as GraphiQL which allow to interact directly with
GraphQL servers.
</pre>
</blockquote>
<pre wrap="">
My point was simply that SDKs provide more than a simple translation
of network API calls and feature discovery. There can also be rather
a lot of "business logic" orchestrating multiple primitive API calls
to reach some more complex outcome. The services don't want to embed
this orchestrated business logic themselves, and it makes little
sense to replicate the same algorithms in every single application
which wants to make use of such composite functionality. There are
common actions an application might wish to take which involve
speaking to multiple APIs for different services to make specific
calls in a particular order, perhaps feeding the results of one into
the next.
Can you explain how GraphQL eliminates the above reasons for an SDK?</pre>
</blockquote>
<br>
What I meant is the communication part of any SDK interfacing
between clients and API services can be handled by GraphQL client
librairies.<br>
So instead of having to rely on modules (imported or native) to
carry the REST communications, we're dealing with data provided by
GraphQL libraries (which are also modules but standardized as
GraphQL is a specification). <br>
So as you mentioned there is still need to provide the data wrap in
objects or any adequate struct to present to the consumers.<br>
<br>
Having a Schema helps both API and clients developers because the
data is clearly typed and graphed. Backend devs can focus on
resolving the data for each node/leaf while the clients can focus on
what they need and not how to get it. <br>
<br>
To relate to $subject, by building the data model (graph) we obtain
a schema and introspection. That's a big saver in term of resources.<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:20181010131849.ey5yf3zxjtevtnae@yuggoth.org">
<pre wrap="">
</pre>
<!--'"--><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>