On 31/05/18 13:08, Ed Leafe wrote:
On May 6, 2018, at 8:01 AM, Gilles Dubreuil <gdubr...@redhat.com> wrote:
Regarding the choice of Neutron as PoC, I'm sorry for not providing much details when I
said "because of its specific data model",
effectively the original mention was "its API exposes things at an individual table
level, requiring the client to join that information to get the answers they need".
I realize now such description probably applies to many OpenStack APIs.
So I'm not sure what was the reason for choosing Neutron.
Blame Monty!
It was Monty who suggested Neutron due to his particular experience working
with the API. Since none of the rest of us in the API-SIG had any better
suggestions, that was what we passed on to you. But I think that any target
that demonstrates the advantages to be had by adopting GraphQL is fine. So if
the team working on this think they can create a more impressive PoC with
another API, the API-SIG will support that.
-- Ed Leafe
Well after being explained the story of the duck versus the duck parts
(liver, heart, etc) it makes sense. With Neutron the API provides lots
of parts but consumers have to put the part together to get the whole.
So Neutron is a good candidate as GraphQL will be able to show how it
can fetch several parts at once (maybe not the whole beast since the PoC
will cover only a fraction of the API).
And as you said as any API it should allow for GraphQL to show it's
performance anyway.
So I believe we're good.
Cheers,
Gilles
__________________________________________________________________________
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
