Open Stack

On 11/10/18 00:18, Jeremy Stanley wrote:
> On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote:
>> On 09/10/18 23:58, Jeremy Stanley wrote:
>>> On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
>>> [...]
>>>> 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?
>>> 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".
>> 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.
> 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?

What I meant is the communication part of any SDK interfacing between 
clients and API services can be handled by GraphQL client librairies.
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).
So as you mentioned there is still need to provide the data wrap in 
objects or any adequate struct to present to the consumers.

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.

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.



>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181011/71176bf0/attachment.html>