Bungee jumping into Quarkus: blindfolded but happy

A year ago I started with a couple of friends a new project based on Quarkus to create a visual editor for integrations called Kaoto.

As responsible of the backend side, I obviously chose Java to do it. Coming from the Java 8 world with shy traces of Java 11, I decided to jump directly to Quarkus on Java 17 (unstable at the time) with Reactive and explore the serverless possibilities while, at the same time, keep the over-engineering and the over-fanciness of new features as reasonable as possible.

On this article I will discuss the good and the bad of this experience. I am not a Quarkus developer, I am a developer that used Quarkus. And as any average developer that starts with a new technology, I obviously skipped the documentation and just bungee jumped into the framework, blindfolded and without safe nets.

Continuar leyendo “Bungee jumping into Quarkus: blindfolded but happy”

Kaoto: Integrate without limits

I would like to present you with an ETL and integration editor Rachel and I have been working on for the past year with the initial help of Zineb: Kaoto.

What is Kaoto?

Kaoto is an integration editor to create and deploy integrations in a low-code way and no-code way based on Apache Camel. It combines a source code editor and a drag and drop graphical space synchronized with each other. It can be run both as standalone and as a service (SaaS).

With the no-code mode, the user can build the entire integration orchestration with the drag and drop function. Kaoto has a step catalog with a list of all available building blocks that the users may want to transform data or integrate with services.

The source code will be available for users curious to know what they are going to deploy. But in no case they have to understand or even see that code.

Example of building block drag and drop

With the low code mode, users can learn how to create integrations and, at the same time, control what they are deploying. They can use both the drag and drop and the source code editor, that will autocomplete what the user won’t or don’t know how to write. Meanwhile the graphical space will show the integration being built and the drag and drop will still be available for them to complete or accelerate the development.

Example of low code integrations.

Kaoto can help users start with Apache Camel and slowly build their knowledge. All the source code generated is clean and viewable in any IDE.

Customizing Kaoto

Each building block type can have its own microfrontend. This is useful when you add your own building blocks to your Kaoto instance. But it can also help adapt Kaoto to different kinds of users, hiding or extending certain details important for each use-case. Extensions can be manuals and helpers for Kaoto.

When used as a service, the extensions and the list of available building blocks are settings that can be stored in the cloud. Therefore, administrator users can modify this configuration, which will refresh live in the users playgrounds. In addition, as this configuration can be in the cloud, different users can share the configuration. This can help organizations accommodate different groups of users, offering different configurations depending on the profile.

What is on the roadmap?

We started the development focused on Kamelet Bindings, but we soon realized we could add more languages. Edition of Apache Camel routes (in yaml form) and Kamelet definitions are next in development queue. We are also working on translating from other integration languages to Camel DSL. This can help users migrate to Apache Camel.

We will soon have one-click support for cloud-native Apache Camel deployments via Camel-K. Matej is close to having an operator for Kubernetes clusters which will simplify even more the installation of Kaoto in the cloud.

You can quickly test it via docker as described on the quickstart. Make sure your docker images have access to internet to be able to access the default remote configuration!

You can find more information on the webpage of the project.

GeoNetwork from Scratch II : Attack of the IDEs

This post was originally posted on the blog of a former company. But since they have decided to violate my authorship rights, here is a copy of it.

We have already seen how to compile and run a basic GeoNetwork instance. Although we know that real developers will probably skip this step too, for new developers in GeoNetwork, it will be relief to have an IDE to work with. I know that many GeoNetwork developers use NetBeans o Intellij but as I am used to work with Eclipse, that’s what we are going to explore on this post.

First of all: Eclipse has better support for Maven projects on each version. So, to avoid headaches, just download the latest eclipse available.Eclipse has many installer tutorials, so I won’t stop here explaining how to run eclipse. I will just assume you know how to do it.

To run GeoNetwork from eclipse is very very easy. Just right click on the Package Explorer view to import -> As Maven Project over the folder you already had cloned on the last post:

Continuar leyendo “GeoNetwork from Scratch II : Attack of the IDEs”