Hi team, I submit a forum [1] named "Cross-project Open API 3.0 support". We can make more discussions about that in this forum in berlin. Feel free to add your ideas here [2]. Welcome to join us. Thanks very much.
[1] https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=open+api [2] https://etherpad.openstack.org/p/api-berlin-forum-brainstorming Best Regards, Edison Xiang On Thu, Oct 11, 2018 at 7:48 PM Gilles Dubreuil <gdubr...@redhat.com> wrote: > > > 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-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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