Quarkus support

[happy-kitty]

Hi.
Quarkus is gaining popularity. It makes the application smaller and speeds it up, particularly at startup.
Making an application Quarkus-friendly requires all its component libraries to become friendly. The problems usually arise in the third-party libraries (using static methods, annotations, etc.). We tried to make Arcade (running in embedded server mode) native/Quarkus friendly. The main problem is with the webserver/websockets - in the libraries io.undertow:undertow-core:2.3.7.Final and org.jboss.xnio:xnio-api:3.8.8.Final. We managed to work around the webserver problems but the websockets are very hard as we'd need to change ArcadeDB code.
So, could we possibly switch ArcadeDB to use alternative webserver/websocket providers that are provided by Quarkus, e.g. like this:

    implementation "io.quarkus.http:quarkus-http-core"
    implementation "io.quarkus.http:quarkus-http-servlet"
    implementation "io.quarkus.http:quarkus-http-websocket-core"
    implementation "io.vertx:vertx-core"
    implementation "io.quarkus.http:quarkus-http-http-core"
    implementation "io.quarkus.http:quarkus-http-vertx-backend"
    implementation "io.quarkus.http:quarkus-http-websocket-servlet"

[lvca]

Do you think refactoring ArcadeDB to have a pluggable httpserver could be the solution? Or just the websocket part?

[odbuser2]

Yes, this would be great. I'm for both quarkus's implementation (and general quarkus support for as much as possible although graalvm native-image is really the goal. Quarkus is just wrapping stuff to make it easier but the best way would be direct native-image support without any help from Quarkus if possible) and any other implementation if it's pluggable. I've used reactor netty for this purpose instead of undertow.

[happy-kitty]

Sure, making a pluggable http server sounds better

[lvca]

Of course if you have something better than Undertow (light and fast), I'm open for a replacement in the default distro

[happy-kitty]

That's exactly what we proposed: Quarkus reimplemented Undertow web server. It's light, fast and can work in both native and JVM environments. However, they didn't follow Undertow's websocket implementation

[lvca]

Ok, so now I'm even more interested in this.

[vic0824]

Undertow v2.3.9 has replaced XNIO with Netty, I don't know if this changes anything.
Whatever solution is adopted, I think it would be really useful to retain the capability of creating user-defined plugins that can register custom http handlers.

[robfrank]

Are you embedding the server behind a quarkus application, or you just need a native image of Arcade?

[happy-kitty]

As we said at the beginning, we use Arcade in embedded server mode inside our application - which we want to make native

[robfrank]

Maybe you can get rid of the server module, if you are using Arcade embedded you just need to rely on the engine module.

[lvca]

You can still connect from the outside world if you run a server as embedded. And this is probably the best way to run ArcadeDB.

[happy-kitty]

We considered and reluctantly rejected this. Both direct DB API and the Web console are too valuable to us (just like on Neo4J that we're trying to move from)

[robfrank]

good point. thank you for clarifying. I worked on a native image POC last year, I'm revamping that branch. It was working, more or less :) . Let me work a bit on it in the next days

[robfrank]

hi, on the branch https://github.com/ArcadeData/arcadedb/tree/poc/native_image there's a preliminary work that works.
Pull the branch and then:

mvn clean install -DskipTests -Pnative

then:

./package/target/arcadedb "-Darcadedb.server.defaultDatabases=Imported[root]{import:https://github.com/ArcadeData/arcadedb-datasets/raw/main/orientdb/OpenBeer.gz}"

open the browser at the address printed out in the console and play with the beers :)

[lvca]

We should run a benchmark on it!