Hey David, I just took a look at Gravitee and like the highly abtracted and modularized approach a lot. Is the project still under active development? I would also be interested in controlling other gateways, e.g. CA API Gateway (which has an API) through Gravitee API-M front-end - is this possible?
Yes, the project is still under highly active development, you can have a look to our github repositories : github.com/gravitee-io
For your other questions, I don't know well how the "other gateways" are running and how they are managed. What you can do from gravitee is to define your API, then export the API's definition in JSON and convert / import the file somewhere else.
Thanks for the quick reply - is there an abstraction for gateways already in Gravitee? Like an API managing the gateway, querying capabilities and apply configuration and service policies.
The common things (auth, throttling, logging, routing, etc) can be implemented on almost every gateway (and you probably know there are many), so I would be highly interested in finding (or contributing to) an API management solution (catalog, subscriptions, etc) which can be used to control different gateway types.
I believe this would be very interesting for many enterprises looking for a central dev portal, but needing to support different gateway technologies, like CA API Gateway, WSO2, Envoy (ingress to Istio), etc.
I was thinking that an abtracted interface to the gateway (like the one you built for storing repository data in Mongo, Redis or via JDBC) could be a way to achieve this.
No there is no abstraction for gateways for now. And nothing about this in our roadmap.
Most of the stuff would be to look on what would be the best format to describe an API, before being able to deploy the API in different gateway technologies.
It is a very interesting feature but also time consuming...
We need a standard to describe an API (inherited from OAI ?) :-)
Ready ? Go !
Hi Chris,
I am a bit late to the discussion but I am really intrigued by your message :-)
Would you be able to share more details on potential use cases you identify?
Why would a company use several gateways?
Thanks
Hi Jean
All companies with API Management projects I have contributed to recently use different gateway vendors internally. This may be due to organizational reasons (lack of coordination between different departments) or technology evolution (central gateway vs micro gateway, advent of service meshes).
In addition I think this could be a door-opener for Gravitee in companies using CA, WSO2 or other vendors with weak developer portal solutions.
Since Gravitee is already highly modularized, the only thing needed is an abstracted API gateway interface (sounds simple, but might be a lot of effort). I'm in discussion with David about it.
Cheers, Chris
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey David, I just took a look at Gravitee and like the highly abtracted and modularized approach a lot. Is the project still under active development? I would also be interested in controlling other gateways, e.g. CA API Gateway (which has an API) through Gravitee API-M front-end - is this possible?
Thanks & cheers, Chris
Hi Chris,
Yes, the project is still under highly active development, you can have a look to our github repositories : github.com/gravitee-io
For your other questions, I don't know well how the "other gateways" are running and how they are managed. What you can do from gravitee is to define your API, then export the API's definition in JSON and convert / import the file somewhere else.
Regards,
Thanks for the quick reply - is there an abstraction for gateways already in Gravitee? Like an API managing the gateway, querying capabilities and apply configuration and service policies.
The common things (auth, throttling, logging, routing, etc) can be implemented on almost every gateway (and you probably know there are many), so I would be highly interested in finding (or contributing to) an API management solution (catalog, subscriptions, etc) which can be used to control different gateway types.
I believe this would be very interesting for many enterprises looking for a central dev portal, but needing to support different gateway technologies, like CA API Gateway, WSO2, Envoy (ingress to Istio), etc.
I was thinking that an abtracted interface to the gateway (like the one you built for storing repository data in Mongo, Redis or via JDBC) could be a way to achieve this.
No there is no abstraction for gateways for now. And nothing about this in our roadmap.
Most of the stuff would be to look on what would be the best format to describe an API, before being able to deploy the API in different gateway technologies.
It is a very interesting feature but also time consuming...
We need a standard to describe an API (inherited from OAI ?) :-)
Ready ? Go !
Hi Chris,
I am a bit late to the discussion but I am really intrigued by your message :-)
Would you be able to share more details on potential use cases you identify?
Why would a company use several gateways?
Thanks
Cheers:
Feel free to PM me on twitter.
Hi Jean
All companies with API Management projects I have contributed to recently use different gateway vendors internally. This may be due to organizational reasons (lack of coordination between different departments) or technology evolution (central gateway vs micro gateway, advent of service meshes).
In addition I think this could be a door-opener for Gravitee in companies using CA, WSO2 or other vendors with weak developer portal solutions.
Since Gravitee is already highly modularized, the only thing needed is an abstracted API gateway interface (sounds simple, but might be a lot of effort). I'm in discussion with David about it.
Cheers, Chris