You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by María Arias de Reyna <de...@apache.org> on 2022/03/24 08:28:33 UTC
Presenting Kaoto
Hello!
I would like to present you a Camel editor Rachel and I have been
working for the past year: Kaoto.
Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
Kaoto has a source code editor and a drag and drop graphical space
that are synchronized with each other.
We started the development focused on Kamelet Bindings, but we soon
realized we could add more DSLs and we are close to have Kamelet and
Camel Route support too. Each Kaoto instance has a list of remote urls
from which to build the catalog of steps or building blocks. We
started a metadata catalog, like the one for Kamelets, to describe
camel connectors to be able to use them also easily in our graphical
editor[1]. This half-done catalog of metadata allows us to add camel
connectors to our integrations. This is an experiment and we would
welcome input on how to make it better, specially if it can be reused
for other purposes.
The user interface is extendable too[2]. With this configuration each
step can have its own microfrontend[3] to configure its properties.
This is not only useful when you add your own steps, but it can also
help you adapt Kaoto to different kinds of users, hiding or extending
certain details important for each use-case.
The idea behind all these catalogs of configuration is not to use git
repositories in production, but to have some configuration that can be
reloaded/refreshed live. Right now we also support zip/jar files with
the configuration, both for the step catalog and the view definitions
catalog. We may want to extend to use some other types of cache, more
k-native style, for when not used as standalone.
We are also working on one-click support for cloud-native Apache Camel
deployments via Camel-K. That's not yet enabled, partly because we
want it to be tied to some form of authentication to allow users to
have their own configuration and deployments.
More information on our webpage: https://kaoto.io/about/
You can quickly test it via docker: https://kaoto.io/quickstart/ Make
sure your docker images have access to internet to be able to access
the kamelet catalogs!
[1] https://github.com/apache/camel-kamelets
[2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
[3] https://martinfowler.com/articles/micro-frontends.html
Re: Presenting Kaoto
Posted by María Arias de Reyna <de...@gmail.com>.
Hi Pasquale!
Thank you :)
Right now we don't have any cross collaboration planned with Karavan.
Although the idea is similar (visual editing of camel DSLs), the way
to implement it is completely different. But maybe we can work on the
common metadata catalog of connectors?
On Thu, Mar 24, 2022 at 11:55 AM Pasquale Congiusti
<pa...@gmail.com> wrote:
>
> Thanks Maria and Rachel,
> excellent stuff! I wonder if you've already explored some cross
> collaboration with Camel Karavan [1]. It looks to me that there are certain
> areas covered by both tools.
>
> Regards,
> Pasquale.
>
> [1] https://github.com/apache/camel-karavan
>
> On Thu, Mar 24, 2022 at 9:29 AM María Arias de Reyna <de...@apache.org>
> wrote:
>
> > Hello!
> >
> > I would like to present you a Camel editor Rachel and I have been
> > working for the past year: Kaoto.
> >
> > Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
> >
> > Kaoto has a source code editor and a drag and drop graphical space
> > that are synchronized with each other.
> >
> > We started the development focused on Kamelet Bindings, but we soon
> > realized we could add more DSLs and we are close to have Kamelet and
> > Camel Route support too. Each Kaoto instance has a list of remote urls
> > from which to build the catalog of steps or building blocks. We
> > started a metadata catalog, like the one for Kamelets, to describe
> > camel connectors to be able to use them also easily in our graphical
> > editor[1]. This half-done catalog of metadata allows us to add camel
> > connectors to our integrations. This is an experiment and we would
> > welcome input on how to make it better, specially if it can be reused
> > for other purposes.
> >
> > The user interface is extendable too[2]. With this configuration each
> > step can have its own microfrontend[3] to configure its properties.
> > This is not only useful when you add your own steps, but it can also
> > help you adapt Kaoto to different kinds of users, hiding or extending
> > certain details important for each use-case.
> >
> > The idea behind all these catalogs of configuration is not to use git
> > repositories in production, but to have some configuration that can be
> > reloaded/refreshed live. Right now we also support zip/jar files with
> > the configuration, both for the step catalog and the view definitions
> > catalog. We may want to extend to use some other types of cache, more
> > k-native style, for when not used as standalone.
> >
> > We are also working on one-click support for cloud-native Apache Camel
> > deployments via Camel-K. That's not yet enabled, partly because we
> > want it to be tied to some form of authentication to allow users to
> > have their own configuration and deployments.
> >
> > More information on our webpage: https://kaoto.io/about/
> >
> > You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> > sure your docker images have access to internet to be able to access
> > the kamelet catalogs!
> >
> > [1] https://github.com/apache/camel-kamelets
> > [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> > [3] https://martinfowler.com/articles/micro-frontends.html
> >
Re: Presenting Kaoto
Posted by María Arias de Reyna <de...@gmail.com>.
Hi Pasquale!
Thank you :)
Right now we don't have any cross collaboration planned with Karavan.
Although the idea is similar (visual editing of camel DSLs), the way
to implement it is completely different. But maybe we can work on the
common metadata catalog of connectors?
On Thu, Mar 24, 2022 at 11:55 AM Pasquale Congiusti
<pa...@gmail.com> wrote:
>
> Thanks Maria and Rachel,
> excellent stuff! I wonder if you've already explored some cross
> collaboration with Camel Karavan [1]. It looks to me that there are certain
> areas covered by both tools.
>
> Regards,
> Pasquale.
>
> [1] https://github.com/apache/camel-karavan
>
> On Thu, Mar 24, 2022 at 9:29 AM María Arias de Reyna <de...@apache.org>
> wrote:
>
> > Hello!
> >
> > I would like to present you a Camel editor Rachel and I have been
> > working for the past year: Kaoto.
> >
> > Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
> >
> > Kaoto has a source code editor and a drag and drop graphical space
> > that are synchronized with each other.
> >
> > We started the development focused on Kamelet Bindings, but we soon
> > realized we could add more DSLs and we are close to have Kamelet and
> > Camel Route support too. Each Kaoto instance has a list of remote urls
> > from which to build the catalog of steps or building blocks. We
> > started a metadata catalog, like the one for Kamelets, to describe
> > camel connectors to be able to use them also easily in our graphical
> > editor[1]. This half-done catalog of metadata allows us to add camel
> > connectors to our integrations. This is an experiment and we would
> > welcome input on how to make it better, specially if it can be reused
> > for other purposes.
> >
> > The user interface is extendable too[2]. With this configuration each
> > step can have its own microfrontend[3] to configure its properties.
> > This is not only useful when you add your own steps, but it can also
> > help you adapt Kaoto to different kinds of users, hiding or extending
> > certain details important for each use-case.
> >
> > The idea behind all these catalogs of configuration is not to use git
> > repositories in production, but to have some configuration that can be
> > reloaded/refreshed live. Right now we also support zip/jar files with
> > the configuration, both for the step catalog and the view definitions
> > catalog. We may want to extend to use some other types of cache, more
> > k-native style, for when not used as standalone.
> >
> > We are also working on one-click support for cloud-native Apache Camel
> > deployments via Camel-K. That's not yet enabled, partly because we
> > want it to be tied to some form of authentication to allow users to
> > have their own configuration and deployments.
> >
> > More information on our webpage: https://kaoto.io/about/
> >
> > You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> > sure your docker images have access to internet to be able to access
> > the kamelet catalogs!
> >
> > [1] https://github.com/apache/camel-kamelets
> > [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> > [3] https://martinfowler.com/articles/micro-frontends.html
> >
Re: Presenting Kaoto
Posted by Pasquale Congiusti <pa...@gmail.com>.
Thanks Maria and Rachel,
excellent stuff! I wonder if you've already explored some cross
collaboration with Camel Karavan [1]. It looks to me that there are certain
areas covered by both tools.
Regards,
Pasquale.
[1] https://github.com/apache/camel-karavan
On Thu, Mar 24, 2022 at 9:29 AM María Arias de Reyna <de...@apache.org>
wrote:
> Hello!
>
> I would like to present you a Camel editor Rachel and I have been
> working for the past year: Kaoto.
>
> Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
>
> Kaoto has a source code editor and a drag and drop graphical space
> that are synchronized with each other.
>
> We started the development focused on Kamelet Bindings, but we soon
> realized we could add more DSLs and we are close to have Kamelet and
> Camel Route support too. Each Kaoto instance has a list of remote urls
> from which to build the catalog of steps or building blocks. We
> started a metadata catalog, like the one for Kamelets, to describe
> camel connectors to be able to use them also easily in our graphical
> editor[1]. This half-done catalog of metadata allows us to add camel
> connectors to our integrations. This is an experiment and we would
> welcome input on how to make it better, specially if it can be reused
> for other purposes.
>
> The user interface is extendable too[2]. With this configuration each
> step can have its own microfrontend[3] to configure its properties.
> This is not only useful when you add your own steps, but it can also
> help you adapt Kaoto to different kinds of users, hiding or extending
> certain details important for each use-case.
>
> The idea behind all these catalogs of configuration is not to use git
> repositories in production, but to have some configuration that can be
> reloaded/refreshed live. Right now we also support zip/jar files with
> the configuration, both for the step catalog and the view definitions
> catalog. We may want to extend to use some other types of cache, more
> k-native style, for when not used as standalone.
>
> We are also working on one-click support for cloud-native Apache Camel
> deployments via Camel-K. That's not yet enabled, partly because we
> want it to be tied to some form of authentication to allow users to
> have their own configuration and deployments.
>
> More information on our webpage: https://kaoto.io/about/
>
> You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> sure your docker images have access to internet to be able to access
> the kamelet catalogs!
>
> [1] https://github.com/apache/camel-kamelets
> [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> [3] https://martinfowler.com/articles/micro-frontends.html
>
Re: Presenting Kaoto
Posted by María Arias de Reyna <de...@apache.org>.
Thank you!
That's very nice of you.
On Thu, Mar 24, 2022 at 10:12 AM ski n <ra...@gmail.com> wrote:
>
> Looks cool, will definitely check it out!
>
> For those who like to give support/star it: https://github.com/KaotoIO
>
> Greets,
>
> Raymond
>
>
> On Thu, Mar 24, 2022 at 9:29 AM María Arias de Reyna <de...@apache.org>
> wrote:
>
> > Hello!
> >
> > I would like to present you a Camel editor Rachel and I have been
> > working for the past year: Kaoto.
> >
> > Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
> >
> > Kaoto has a source code editor and a drag and drop graphical space
> > that are synchronized with each other.
> >
> > We started the development focused on Kamelet Bindings, but we soon
> > realized we could add more DSLs and we are close to have Kamelet and
> > Camel Route support too. Each Kaoto instance has a list of remote urls
> > from which to build the catalog of steps or building blocks. We
> > started a metadata catalog, like the one for Kamelets, to describe
> > camel connectors to be able to use them also easily in our graphical
> > editor[1]. This half-done catalog of metadata allows us to add camel
> > connectors to our integrations. This is an experiment and we would
> > welcome input on how to make it better, specially if it can be reused
> > for other purposes.
> >
> > The user interface is extendable too[2]. With this configuration each
> > step can have its own microfrontend[3] to configure its properties.
> > This is not only useful when you add your own steps, but it can also
> > help you adapt Kaoto to different kinds of users, hiding or extending
> > certain details important for each use-case.
> >
> > The idea behind all these catalogs of configuration is not to use git
> > repositories in production, but to have some configuration that can be
> > reloaded/refreshed live. Right now we also support zip/jar files with
> > the configuration, both for the step catalog and the view definitions
> > catalog. We may want to extend to use some other types of cache, more
> > k-native style, for when not used as standalone.
> >
> > We are also working on one-click support for cloud-native Apache Camel
> > deployments via Camel-K. That's not yet enabled, partly because we
> > want it to be tied to some form of authentication to allow users to
> > have their own configuration and deployments.
> >
> > More information on our webpage: https://kaoto.io/about/
> >
> > You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> > sure your docker images have access to internet to be able to access
> > the kamelet catalogs!
> >
> > [1] https://github.com/apache/camel-kamelets
> > [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> > [3] https://martinfowler.com/articles/micro-frontends.html
> >
Re: Presenting Kaoto
Posted by ski n <ra...@gmail.com>.
Looks cool, will definitely check it out!
For those who like to give support/star it: https://github.com/KaotoIO
Greets,
Raymond
On Thu, Mar 24, 2022 at 9:29 AM María Arias de Reyna <de...@apache.org>
wrote:
> Hello!
>
> I would like to present you a Camel editor Rachel and I have been
> working for the past year: Kaoto.
>
> Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
>
> Kaoto has a source code editor and a drag and drop graphical space
> that are synchronized with each other.
>
> We started the development focused on Kamelet Bindings, but we soon
> realized we could add more DSLs and we are close to have Kamelet and
> Camel Route support too. Each Kaoto instance has a list of remote urls
> from which to build the catalog of steps or building blocks. We
> started a metadata catalog, like the one for Kamelets, to describe
> camel connectors to be able to use them also easily in our graphical
> editor[1]. This half-done catalog of metadata allows us to add camel
> connectors to our integrations. This is an experiment and we would
> welcome input on how to make it better, specially if it can be reused
> for other purposes.
>
> The user interface is extendable too[2]. With this configuration each
> step can have its own microfrontend[3] to configure its properties.
> This is not only useful when you add your own steps, but it can also
> help you adapt Kaoto to different kinds of users, hiding or extending
> certain details important for each use-case.
>
> The idea behind all these catalogs of configuration is not to use git
> repositories in production, but to have some configuration that can be
> reloaded/refreshed live. Right now we also support zip/jar files with
> the configuration, both for the step catalog and the view definitions
> catalog. We may want to extend to use some other types of cache, more
> k-native style, for when not used as standalone.
>
> We are also working on one-click support for cloud-native Apache Camel
> deployments via Camel-K. That's not yet enabled, partly because we
> want it to be tied to some form of authentication to allow users to
> have their own configuration and deployments.
>
> More information on our webpage: https://kaoto.io/about/
>
> You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> sure your docker images have access to internet to be able to access
> the kamelet catalogs!
>
> [1] https://github.com/apache/camel-kamelets
> [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> [3] https://martinfowler.com/articles/micro-frontends.html
>
Re: Presenting Kaoto
Posted by María Arias de Reyna <de...@apache.org>.
Hi Ralf!
We are working on releasing "good first issues" for newcomers, so you
are more than welcome to participate in the capacity you can/want!
Thank you for your kind words.
María.
On Thu, Mar 24, 2022 at 10:12 AM Ralf Claussnitzer
<ra...@slub-dresden.de> wrote:
>
> Hi Mariá, hi Rachel,
>
> that is an impressive tool! I was thinking that such a thing should be
> relatively easy to start off and extend. Thanks for this contribution!
> Docker, website, source code, documentation - all polished and very
> inviting. I hope we can use it and help develop it in the future. Good job!
>
> Regards,
> Ralf
>
> On 3/24/22 09:28, María Arias de Reyna wrote:
> > Hello!
> >
> > I would like to present you a Camel editor Rachel and I have been
> > working for the past year: Kaoto.
> >
> > Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
> >
> > Kaoto has a source code editor and a drag and drop graphical space
> > that are synchronized with each other.
> >
> > We started the development focused on Kamelet Bindings, but we soon
> > realized we could add more DSLs and we are close to have Kamelet and
> > Camel Route support too. Each Kaoto instance has a list of remote urls
> > from which to build the catalog of steps or building blocks. We
> > started a metadata catalog, like the one for Kamelets, to describe
> > camel connectors to be able to use them also easily in our graphical
> > editor[1]. This half-done catalog of metadata allows us to add camel
> > connectors to our integrations. This is an experiment and we would
> > welcome input on how to make it better, specially if it can be reused
> > for other purposes.
> >
> > The user interface is extendable too[2]. With this configuration each
> > step can have its own microfrontend[3] to configure its properties.
> > This is not only useful when you add your own steps, but it can also
> > help you adapt Kaoto to different kinds of users, hiding or extending
> > certain details important for each use-case.
> >
> > The idea behind all these catalogs of configuration is not to use git
> > repositories in production, but to have some configuration that can be
> > reloaded/refreshed live. Right now we also support zip/jar files with
> > the configuration, both for the step catalog and the view definitions
> > catalog. We may want to extend to use some other types of cache, more
> > k-native style, for when not used as standalone.
> >
> > We are also working on one-click support for cloud-native Apache Camel
> > deployments via Camel-K. That's not yet enabled, partly because we
> > want it to be tied to some form of authentication to allow users to
> > have their own configuration and deployments.
> >
> > More information on our webpage: https://kaoto.io/about/
> >
> > You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> > sure your docker images have access to internet to be able to access
> > the kamelet catalogs!
> >
> > [1] https://github.com/apache/camel-kamelets
> > [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> > [3] https://martinfowler.com/articles/micro-frontends.html
Re: Presenting Kaoto
Posted by Ralf Claussnitzer <ra...@slub-dresden.de>.
Hi Mariá, hi Rachel,
that is an impressive tool! I was thinking that such a thing should be
relatively easy to start off and extend. Thanks for this contribution!
Docker, website, source code, documentation - all polished and very
inviting. I hope we can use it and help develop it in the future. Good job!
Regards,
Ralf
On 3/24/22 09:28, María Arias de Reyna wrote:
> Hello!
>
> I would like to present you a Camel editor Rachel and I have been
> working for the past year: Kaoto.
>
> Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
>
> Kaoto has a source code editor and a drag and drop graphical space
> that are synchronized with each other.
>
> We started the development focused on Kamelet Bindings, but we soon
> realized we could add more DSLs and we are close to have Kamelet and
> Camel Route support too. Each Kaoto instance has a list of remote urls
> from which to build the catalog of steps or building blocks. We
> started a metadata catalog, like the one for Kamelets, to describe
> camel connectors to be able to use them also easily in our graphical
> editor[1]. This half-done catalog of metadata allows us to add camel
> connectors to our integrations. This is an experiment and we would
> welcome input on how to make it better, specially if it can be reused
> for other purposes.
>
> The user interface is extendable too[2]. With this configuration each
> step can have its own microfrontend[3] to configure its properties.
> This is not only useful when you add your own steps, but it can also
> help you adapt Kaoto to different kinds of users, hiding or extending
> certain details important for each use-case.
>
> The idea behind all these catalogs of configuration is not to use git
> repositories in production, but to have some configuration that can be
> reloaded/refreshed live. Right now we also support zip/jar files with
> the configuration, both for the step catalog and the view definitions
> catalog. We may want to extend to use some other types of cache, more
> k-native style, for when not used as standalone.
>
> We are also working on one-click support for cloud-native Apache Camel
> deployments via Camel-K. That's not yet enabled, partly because we
> want it to be tied to some form of authentication to allow users to
> have their own configuration and deployments.
>
> More information on our webpage: https://kaoto.io/about/
>
> You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> sure your docker images have access to internet to be able to access
> the kamelet catalogs!
>
> [1] https://github.com/apache/camel-kamelets
> [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> [3] https://martinfowler.com/articles/micro-frontends.html
Re: Presenting Kaoto
Posted by Pasquale Congiusti <pa...@gmail.com>.
Thanks Maria and Rachel,
excellent stuff! I wonder if you've already explored some cross
collaboration with Camel Karavan [1]. It looks to me that there are certain
areas covered by both tools.
Regards,
Pasquale.
[1] https://github.com/apache/camel-karavan
On Thu, Mar 24, 2022 at 9:29 AM María Arias de Reyna <de...@apache.org>
wrote:
> Hello!
>
> I would like to present you a Camel editor Rachel and I have been
> working for the past year: Kaoto.
>
> Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
>
> Kaoto has a source code editor and a drag and drop graphical space
> that are synchronized with each other.
>
> We started the development focused on Kamelet Bindings, but we soon
> realized we could add more DSLs and we are close to have Kamelet and
> Camel Route support too. Each Kaoto instance has a list of remote urls
> from which to build the catalog of steps or building blocks. We
> started a metadata catalog, like the one for Kamelets, to describe
> camel connectors to be able to use them also easily in our graphical
> editor[1]. This half-done catalog of metadata allows us to add camel
> connectors to our integrations. This is an experiment and we would
> welcome input on how to make it better, specially if it can be reused
> for other purposes.
>
> The user interface is extendable too[2]. With this configuration each
> step can have its own microfrontend[3] to configure its properties.
> This is not only useful when you add your own steps, but it can also
> help you adapt Kaoto to different kinds of users, hiding or extending
> certain details important for each use-case.
>
> The idea behind all these catalogs of configuration is not to use git
> repositories in production, but to have some configuration that can be
> reloaded/refreshed live. Right now we also support zip/jar files with
> the configuration, both for the step catalog and the view definitions
> catalog. We may want to extend to use some other types of cache, more
> k-native style, for when not used as standalone.
>
> We are also working on one-click support for cloud-native Apache Camel
> deployments via Camel-K. That's not yet enabled, partly because we
> want it to be tied to some form of authentication to allow users to
> have their own configuration and deployments.
>
> More information on our webpage: https://kaoto.io/about/
>
> You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> sure your docker images have access to internet to be able to access
> the kamelet catalogs!
>
> [1] https://github.com/apache/camel-kamelets
> [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> [3] https://martinfowler.com/articles/micro-frontends.html
>
Re: Presenting Kaoto
Posted by María Arias de Reyna <de...@apache.org>.
Hi Bert!
We are working on this now: the ability to pass this variable to the
frontend without rebuilding. I hope Matej pushes it soon.
Thank you!
María.
On Thu, Mar 24, 2022 at 11:27 AM Bert Speckels <be...@gmail.com> wrote:
>
> Looks very promising!
>
> I would like to give it a try and follow your further development.
>
> I have a first question:
>
> What can I do, when the backend port (8081) is already in use and I mapo
> that port to 9081:
> docker run --rm -d -p 9081:8081 --name kaoto-backend kaotoio/backend
>
> How can I specify the backend port for the frontend?
>
> With kind regards
> Bert Speckels
>
> Am Do., 24. März 2022 um 09:29 Uhr schrieb María Arias de Reyna <
> delawen@apache.org>:
>
> > Hello!
> >
> > I would like to present you a Camel editor Rachel and I have been
> > working for the past year: Kaoto.
> >
> > Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
> >
> > Kaoto has a source code editor and a drag and drop graphical space
> > that are synchronized with each other.
> >
> > We started the development focused on Kamelet Bindings, but we soon
> > realized we could add more DSLs and we are close to have Kamelet and
> > Camel Route support too. Each Kaoto instance has a list of remote urls
> > from which to build the catalog of steps or building blocks. We
> > started a metadata catalog, like the one for Kamelets, to describe
> > camel connectors to be able to use them also easily in our graphical
> > editor[1]. This half-done catalog of metadata allows us to add camel
> > connectors to our integrations. This is an experiment and we would
> > welcome input on how to make it better, specially if it can be reused
> > for other purposes.
> >
> > The user interface is extendable too[2]. With this configuration each
> > step can have its own microfrontend[3] to configure its properties.
> > This is not only useful when you add your own steps, but it can also
> > help you adapt Kaoto to different kinds of users, hiding or extending
> > certain details important for each use-case.
> >
> > The idea behind all these catalogs of configuration is not to use git
> > repositories in production, but to have some configuration that can be
> > reloaded/refreshed live. Right now we also support zip/jar files with
> > the configuration, both for the step catalog and the view definitions
> > catalog. We may want to extend to use some other types of cache, more
> > k-native style, for when not used as standalone.
> >
> > We are also working on one-click support for cloud-native Apache Camel
> > deployments via Camel-K. That's not yet enabled, partly because we
> > want it to be tied to some form of authentication to allow users to
> > have their own configuration and deployments.
> >
> > More information on our webpage: https://kaoto.io/about/
> >
> > You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> > sure your docker images have access to internet to be able to access
> > the kamelet catalogs!
> >
> > [1] https://github.com/apache/camel-kamelets
> > [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> > [3] https://martinfowler.com/articles/micro-frontends.html
> >
Re: Presenting Kaoto
Posted by Bert Speckels <be...@gmail.com>.
Looks very promising!
I would like to give it a try and follow your further development.
I have a first question:
What can I do, when the backend port (8081) is already in use and I mapo
that port to 9081:
docker run --rm -d -p 9081:8081 --name kaoto-backend kaotoio/backend
How can I specify the backend port for the frontend?
With kind regards
Bert Speckels
Am Do., 24. März 2022 um 09:29 Uhr schrieb María Arias de Reyna <
delawen@apache.org>:
> Hello!
>
> I would like to present you a Camel editor Rachel and I have been
> working for the past year: Kaoto.
>
> Kaoto is an acronym for **Ka**mel **O**rchestration **To**ol.
>
> Kaoto has a source code editor and a drag and drop graphical space
> that are synchronized with each other.
>
> We started the development focused on Kamelet Bindings, but we soon
> realized we could add more DSLs and we are close to have Kamelet and
> Camel Route support too. Each Kaoto instance has a list of remote urls
> from which to build the catalog of steps or building blocks. We
> started a metadata catalog, like the one for Kamelets, to describe
> camel connectors to be able to use them also easily in our graphical
> editor[1]. This half-done catalog of metadata allows us to add camel
> connectors to our integrations. This is an experiment and we would
> welcome input on how to make it better, specially if it can be reused
> for other purposes.
>
> The user interface is extendable too[2]. With this configuration each
> step can have its own microfrontend[3] to configure its properties.
> This is not only useful when you add your own steps, but it can also
> help you adapt Kaoto to different kinds of users, hiding or extending
> certain details important for each use-case.
>
> The idea behind all these catalogs of configuration is not to use git
> repositories in production, but to have some configuration that can be
> reloaded/refreshed live. Right now we also support zip/jar files with
> the configuration, both for the step catalog and the view definitions
> catalog. We may want to extend to use some other types of cache, more
> k-native style, for when not used as standalone.
>
> We are also working on one-click support for cloud-native Apache Camel
> deployments via Camel-K. That's not yet enabled, partly because we
> want it to be tied to some form of authentication to allow users to
> have their own configuration and deployments.
>
> More information on our webpage: https://kaoto.io/about/
>
> You can quickly test it via docker: https://kaoto.io/quickstart/ Make
> sure your docker images have access to internet to be able to access
> the kamelet catalogs!
>
> [1] https://github.com/apache/camel-kamelets
> [2] https://github.com/KaotoIO/kaoto-viewdefinition-catalog
> [3] https://martinfowler.com/articles/micro-frontends.html
>