Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

Ok, here are my two cents regarding GraphQL integration within Openstack
and some thoughts around this topic.

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 :

• 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.

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.
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.
Additionally it streamline our support and debug processes.

• We should get a common consensus before all projects start to implement
it.

This point is for me the most important one as it will fix flaws we get
currently with the rest APIs development within Openstack.

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.

Having too many options even if explained within the documentation daunt a
lot of people to quickly give a hand with projects.

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.

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...

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.

That would also have the side effect to easy the entry level for a new
Openstack developer.

• New architecture opportunities.

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.

I personally don’t like centralized services as it bring SPOF.

Let’s take the AMQP example. For now most of Openstack deployments use a
RabbitMQ or broker like system.
Even if each (well at least major vanilla projects) services can (and
should) use ZeroMQ.
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.

One thing that I would love to see with GraphQL is a better distributed and
traceable model.

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.
Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil  a écrit :

>
>
> On 01/05/18 11:31, Flint WALRUS wrote:
>
> Yes, that’s was indeed the sens of my point.
>
>
> I was just enforcing it, no worries! ;)
>
>
>
> Openstack have to provide both endpoints type for a while for backward
> compatibility in order to smooth the transition.
>
> 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.
>
>
> Shouldn't we have a common consensus before any project start pushing its
> own GraphQL wheel?
>
> Also I wonder how GraphQL could open new architecture avenues for
> OpenStack.
> For example, would that make sense to also have a GraphQL broker linking
> OpenStack services?
>
>
>
>
> Or alternatively to provide a tool with similar features at least.
> Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil  a
> écrit :
>
>>
>>
>> On 30/04/18 20:16, Flint WALRUS wrote:
>>
>> I would very much second that question! Indeed it have been one of my own
>> wondering since many times.
>>
>> Of course GraphQL is not intended to replace REST as is and have to live
>> in parallel
>>
>>
>> Effectively a standard initial architecture is to have GraphQL sitting
>> aside (in parallel) and wrapping REST and along the way develop GrapgQL
>> Schema.
>>
>> It's seems too early to tell but GraphQL being the next step in API
>> evolution it might ultimately replace REST.
>>
>>
>> but it would likely and highly accelerate all requests within heavily
>> loaded environments
>>
>>
>> +1
>>
>>
>> .
>>
>> So +1 for this question.
>> Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
>> écrit :
>>
>>> Hi,
>>>
>>> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
>>> addresses REST limitations.

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 01/05/18 11:31, Flint WALRUS wrote:

Yes, that’s was indeed the sens of my point.


I was just enforcing it, no worries! ;)



Openstack have to provide both endpoints type for a while for backward 
compatibility in order to smooth the transition.


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.


Shouldn't we have a common consensus before any project start pushing 
its own GraphQL wheel?


Also I wonder how GraphQL could open new architecture avenues for OpenStack.
For example, would that make sense to also have a GraphQL broker linking 
OpenStack services?





Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil > a écrit :




On 30/04/18 20:16, Flint WALRUS wrote:

I would very much second that question! Indeed it have been one
of my own wondering since many times.

Of course GraphQL is not intended to replace REST as is and have
to live in parallel 


Effectively a standard initial architecture is to have GraphQL
sitting aside (in parallel) and wrapping REST and along the way
develop GrapgQL Schema.

It's seems too early to tell but GraphQL being the next step in
API evolution it might ultimately replace REST.



but it would likely and highly accelerate all requests within
heavily loaded environments


+1



.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil
> a écrit :

Hi,

Remember Boston's Summit presentation [1] about GraphQL [2]
and how it
addresses REST limitations.
I wonder if any project has been thinking about using
GraphQL. I haven't
find any mention or pointers about it.

GraphQL takes a complete different approach compared to REST.
So we can
finally forget about REST API Description languages
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the
hypermedia
approach which doesn't describe how to use it).

So, once passed the point where 'REST vs GraphQL' is like
comparing SQL
and no-SQL DBMS and therefore have different applications,
there are no
doubt the complexity of most OpenStack projects are good
candidates for
GraphQL.

Besides topics such as efficiency, decoupling, no version
management
need there many other powerful features such as API Schema
out of the
box and better automation down that track.

It looks like the dream of a conduit between API services and
consumers
might have finally come true so we could move-on an worry
about other
things.

So has anyone already starting looking into it?

[1]

https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
[2] http://graphql.org




__
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



-- 
Gilles Dubreuil

Senior Software Engineer - Red Hat - Openstack DFG Integration
Email:gil...@redhat.com 
GitHub/IRC: gildub
Mobile: +61 400 894 219



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
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

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 01/05/18 07:21, Matt Riedemann wrote:

On 4/29/2018 10:53 PM, Gilles Dubreuil wrote:
Remember Boston's Summit presentation [1] about GraphQL [2] and how 
it addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I 
haven't find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we 
can finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing 
SQL and no-SQL DBMS and therefore have different applications, there 
are no doubt the complexity of most OpenStack projects are good 
candidates for GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and 
consumers might have finally come true so we could move-on an worry 
about other things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql 


[2] http://graphql.org


Not to speak for him, but Sean Dague had a blog post about REST API 
microversions in OpenStack and there is a Q bit at the bottom about 
GraphQL replacing the need for microversions:


https://dague.net/2017/12/11/rest-api-microversions/

Since I don't expect Sean to magically appear to reply to this thread, 
I thought I'd pass this along.




Thanks Matt for the link.

During Denver's PTG we effectively discovered consumers tend to use 3rd 
party SDK and we also discovered that, ironically, nobody - besides Sean 
;) - has the bandwidth to work full time on SDK either. That was and 
still is the driver for more automation and therefore for having 
projects to produce an API Schema.


Once aspect is about GraphQL being a descriptive language. It allow to 
decouple entirely consumers from producers. So instead of SDK, consumers 
rely on GraphQL client library (which are standardized [1]). The focus 
becomes the data and not how to transfer the data.
Effectively, services make their data available through a Schema and 
clients request a tree of data against it. Sure, at the end of the day, 
it's still a HTTP conversation taking place and returning a JSON 
structure (when not up/down loading a file or so). The big difference 
(among other things) is one and only one transaction is used.


The second aspect is about automation which can take place because the 
Schema is provided up-front, it's the Graph part.


In the Q, Sean said SDK "build their object models", yes that's true 
with GraphQL we have "fat clients" but as we've also seen the SDK is 
replaced with a GraphQL client., cutting the "man in the middle" off!


As per the rest of the Answer, it seems to me there are other aspects to 
be looked at it from different angles.


Cheers

[1] http://graphql.org/code/



__
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

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

Yes, that’s was indeed the sens of my point.

Openstack have to provide both endpoints type for a while for backward
compatibility in order to smooth the transition.

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.

Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil  a écrit :

>
>
> On 30/04/18 20:16, Flint WALRUS wrote:
>
> I would very much second that question! Indeed it have been one of my own
> wondering since many times.
>
> Of course GraphQL is not intended to replace REST as is and have to live
> in parallel
>
>
> Effectively a standard initial architecture is to have GraphQL sitting
> aside (in parallel) and wrapping REST and along the way develop GrapgQL
> Schema.
>
> It's seems too early to tell but GraphQL being the next step in API
> evolution it might ultimately replace REST.
>
>
> but it would likely and highly accelerate all requests within heavily
> loaded environments
>
>
> +1
>
>
> .
>
> So +1 for this question.
> Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
> écrit :
>
>> Hi,
>>
>> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
>> addresses REST limitations.
>> I wonder if any project has been thinking about using GraphQL. I haven't
>> find any mention or pointers about it.
>>
>> GraphQL takes a complete different approach compared to REST. So we can
>> finally forget about REST API Description languages
>> (OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
>> approach which doesn't describe how to use it).
>>
>> So, once passed the point where 'REST vs GraphQL' is like comparing SQL
>> and no-SQL DBMS and therefore have different applications, there are no
>> doubt the complexity of most OpenStack projects are good candidates for
>> GraphQL.
>>
>> Besides topics such as efficiency, decoupling, no version management
>> need there many other powerful features such as API Schema out of the
>> box and better automation down that track.
>>
>> It looks like the dream of a conduit between API services and consumers
>> might have finally come true so we could move-on an worry about other
>> things.
>>
>> So has anyone already starting looking into it?
>>
>> [1]
>>
>> https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
>> [2] http://graphql.org
>>
>>
>>
>> __
>> 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
>>
>
> --
> Gilles Dubreuil
> Senior Software Engineer - Red Hat - Openstack DFG Integration
> Email: gil...@redhat.com
> GitHub/IRC: gildub
> Mobile: +61 400 894 219
>
>
>
__
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

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 30/04/18 20:16, Flint WALRUS wrote:
I would very much second that question! Indeed it have been one of my 
own wondering since many times.


Of course GraphQL is not intended to replace REST as is and have to 
live in parallel 


Effectively a standard initial architecture is to have GraphQL sitting 
aside (in parallel) and wrapping REST and along the way develop GrapgQL 
Schema.


It's seems too early to tell but GraphQL being the next step in API 
evolution it might ultimately replace REST.


but it would likely and highly accelerate all requests within heavily 
loaded environments


+1


.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil > a écrit :


Hi,

Remember Boston's Summit presentation [1] about GraphQL [2] and
how it
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I
haven't
find any mention or pointers about it.

GraphQL takes a complete different approach compared to REST. So
we can
finally forget about REST API Description languages
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
approach which doesn't describe how to use it).

So, once passed the point where 'REST vs GraphQL' is like
comparing SQL
and no-SQL DBMS and therefore have different applications, there
are no
doubt the complexity of most OpenStack projects are good
candidates for
GraphQL.

Besides topics such as efficiency, decoupling, no version management
need there many other powerful features such as API Schema out of the
box and better automation down that track.

It looks like the dream of a conduit between API services and
consumers
might have finally come true so we could move-on an worry about other
things.

So has anyone already starting looking into it?

[1]

https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
[2] http://graphql.org



__
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



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
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

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Matt Riedemann]

On 4/29/2018 10:53 PM, Gilles Dubreuil wrote:
Remember Boston's Summit presentation [1] about GraphQL [2] and how it 
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I haven't 
find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we can 
finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing SQL 
and no-SQL DBMS and therefore have different applications, there are no 
doubt the complexity of most OpenStack projects are good candidates for 
GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and consumers 
might have finally come true so we could move-on an worry about other 
things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql 


[2] http://graphql.org


Not to speak for him, but Sean Dague had a blog post about REST API 
microversions in OpenStack and there is a Q bit at the bottom about 
GraphQL replacing the need for microversions:


https://dague.net/2017/12/11/rest-api-microversions/

Since I don't expect Sean to magically appear to reply to this thread, I 
thought I'd pass this along.


--

Thanks,

Matt

__
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

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

I would very much second that question! Indeed it have been one of my own
wondering since many times.

Of course GraphQL is not intended to replace REST as is and have to live in
parallel but it would likely and highly accelerate all requests within
heavily loaded environments.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
écrit :

> Hi,
>
> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
> addresses REST limitations.
> I wonder if any project has been thinking about using GraphQL. I haven't
> find any mention or pointers about it.
>
> GraphQL takes a complete different approach compared to REST. So we can
> finally forget about REST API Description languages
> (OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
> approach which doesn't describe how to use it).
>
> So, once passed the point where 'REST vs GraphQL' is like comparing SQL
> and no-SQL DBMS and therefore have different applications, there are no
> doubt the complexity of most OpenStack projects are good candidates for
> GraphQL.
>
> Besides topics such as efficiency, decoupling, no version management
> need there many other powerful features such as API Schema out of the
> box and better automation down that track.
>
> It looks like the dream of a conduit between API services and consumers
> might have finally come true so we could move-on an worry about other
> things.
>
> So has anyone already starting looking into it?
>
> [1]
>
> https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
> [2] http://graphql.org
>
>
>
> __
> 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

[openstack-dev] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

Hi,

Remember Boston's Summit presentation [1] about GraphQL [2] and how it 
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I haven't 
find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we can 
finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing SQL 
and no-SQL DBMS and therefore have different applications, there are no 
doubt the complexity of most OpenStack projects are good candidates for 
GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and consumers 
might have finally come true so we could move-on an worry about other 
things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql

[2] http://graphql.org



__
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