Vert.x Hacks

Secure Vert.x IDE setup

Thu, 15 Sep 2022 00:00:00 +0000

I recently had to re-install my laptop and noticed that my IDE stop giving me the hints I was used to get regarding secure code tips.

I’m putting the short setup here so, I can always recall it whenever I have to go over the process again in the future.

First of all I use both a mix of command line and graphical tools. This means that at the CLI level I have installed:

maven
openjdk

Usually I just rely on the linux packages from the distribution. While maven usually just works as vert.x builds are not that fancy, sometimes I need to switch JDKs. To switch JDK I’ve this simple bash script in my .bashrc:

export JVM_PATH=${PATH}
_comp_jvm () {
    # Get list of directories
    # $2 is the word being completed
    COMPREPLY=($(compgen -d "${HOME}"/.jdks/"$2"))
    # Reduce to basenames
    COMPREPLY=("${COMPREPLY[@]##*/}")
}
complete -F _comp_jvm jvm
jvm () {
    # Set the path to use the choosen JVM by default
    export PATH="${HOME}"/.jdks/"$1"/bin:${JVM_PATH}
    # Set JAVA_HOME
    export JAVA_HOME="${HOME}"/.jdks/"$1"
    java -version
}

This will allow me to switch from JVM at the CLI cycling any JDKs installed in ~/.jdks. This is usually the location IntelliJ Idea will download JDKs, so I don’t rely on any other tools. The _comp_jvm function just allows me to list the available JDKs using Tab completion.

For graphical development I’m using IntelliJ Idea. There are a couple of features I enable. Once you open a vert.x module you can enable null checks for vert.x code by:

Go to settings
Build, Execution, Deployment
Compiler
Nullable Annotations
+ (add)
io.vertx.codegen.annotations.Nullable

After this we can add the SpotBugs plugin to give you extra hints of potential bugs in your code:

While IDEA will already give you good hints on your code, I’m more interested on a sub-plugin, so you need to:

Go to settings
Tools
SpotBugs
+ (add)
find-sec-bugs

This will allow us to run extra checks related to security.

That’s it for now!

Happy coding!

The power of Open-Source

Wed, 13 Apr 2022 00:00:00 +0000

I had the chance of chatting about the power of open-source on the Beyond Coding Podcast.

It was a lot of fun to share ideas and discuss why open source can be hard to get started but highly rewarding.

Passwordless FIDO2/WebAuthn 101: Or how to build strong security and stop worry about data breaches

Thu, 20 Jan 2022 08:00:00 +0000

The end of password-based authentication is near. Weak passwords are the cause of endless security breaches, and the constant reuse of the same password across different accounts is what keeps the clock ticking for the next breach to happen.

The FIDO2 standard aims to replace passwords entirely, and there is a good deal of chance that it will succeed. It has gained significant momentum in the past couple of years, as all major browser and operating system vendors fully jumped on board.

This talk will provide a deep dive of the FIDO2 and W3C WebAuthn standards, with the main focus on how to quickly implement it on any JVM/GraalVM based application using open-source FIDO Alliance conformant libraries.

Best practices, including security token lifecycle management, will also be covered.

This was the abstract of my talk at JFall’21. Here’s the recording:

Source Example

package com.example.webauthn;

import io.vertx.core.AbstractVerticle;
import io.vertx.core.Promise;
import io.vertx.core.http.CookieSameSite;
import io.vertx.core.http.HttpServerOptions;
import io.vertx.core.net.JksOptions;
import io.vertx.ext.auth.webauthn.RelyingParty;
import io.vertx.ext.auth.webauthn.WebAuthn;
import io.vertx.ext.auth.webauthn.WebAuthnOptions;
import io.vertx.ext.web.Router;
import io.vertx.ext.web.handler.*;
import io.vertx.ext.web.sstore.LocalSessionStore;

public class MainVerticle extends AbstractVerticle {

    @Override
    public void start(Promise<Void> start) {

        // Dummy database, real world workloads
        // use a persistent store or course!
        final InMemoryStore database = new InMemoryStore();

        // create the webauthn security object
        WebAuthn webAuthN = WebAuthn.create(
                        vertx,
                        new WebAuthnOptions()
                                .setRelyingParty(new RelyingParty().setName("Vert.x Demo Server")))
                // where to load/update authenticators data
                .authenticatorFetcher(database::fetcher)
                .authenticatorUpdater(database::updater);

        final Router app = Router.router(vertx);
        // parse the BODY
        app.post()
                .handler(BodyHandler.create());
        // favicon
        app.route()
                .handler(FaviconHandler.create(vertx));
        // add a session handler
        app.route()
                .handler(SessionHandler
                        .create(LocalSessionStore.create(vertx))
                        .setCookieSameSite(CookieSameSite.STRICT));

        // security handler
        WebAuthnHandler webAuthnHandler = WebAuthnHandler.create(webAuthN)
                .setOrigin(String.format("https://%s.nip.io:8443", System.getenv("IP")))
                // required callback
                .setupCallback(app.post("/webauthn/callback"))
                // optional register callback
                .setupCredentialsCreateCallback(app.post("/webauthn/register"))
                // optional login callback
                .setupCredentialsGetCallback(app.post("/webauthn/login"));

        // secure the remaining routes
        app.route("/protected/*").handler(webAuthnHandler);

        // serve the SPA
        app.route()
                .handler(StaticHandler.create());

        vertx.createHttpServer(
                        new HttpServerOptions()
                                .setSsl(true)
                                .setKeyStoreOptions(
                                        new JksOptions()
                                                .setPath("cert-store.jks")
                                                .setPassword(System.getenv("CERTSTORE_SECRET"))))

                .requestHandler(app)
                .listen(8443, "0.0.0.0")
                .onFailure(start::fail)
                .onSuccess(v -> {
                    System.out.printf("Server listening at: https://%s.nip.io:8443%n", System.getenv("IP"));
                    start.complete();
                });
    }
}

Instant Passwordless JVM apps with Vert.x and FIDO2

Fri, 07 Jan 2022 08:00:00 +0000

The history around passwords is blurry as the invention of the wheel. Most people say that one of the first usages was in the mid nineteen sixties, when MIT was building the Compatible Time-Sharing System (CTSS). This was a 30 million dollar computer, that was being shared between users.

    Quickly there was a need to keep private homes for each user. Computing resources and storage were scarce at that time
    so the solution was to store a secret (the password) that would be checked against the user login and verify the
    identity.

Many years later, around 1989, Tim Berners-Lee developed the HTTP protocol which allowed us to have the internet as we know it today. Since then, many standards have been defined:

HTTP Basic Authentication - Which encodes usernames and passwords in Base64, which by the way, is not a encryption algorithm.
HTTP Digest Authentication - Which improves the previous status quo by hashing using MD5 the user credentials with the requested resource HTTP method and URI. By today’s standard, MD5 is not considered secure and should be avoided as it can be brute forced in a very short amount of time.
HTTP Bearer tokens - Which improves the security by using better hashing algorithms, yet doesn’t solve issues such as replay attacks
Form based Authentication - Where developers “invent” their own security, which sadly ends up on big security breaches.
One Time Password - Using authenticators with a pre shared key. Given that the key is pre-shared, it can be leaked easily.

And we could be keep the list going if we wanted…

What’s wrong with the status quo?

So what is wrong with the status quo? Well, the world has now billions of connected devices to the internet. Dozens of authentication mechanisms, which sadly all have big flaws. Let me just list a couple of well know security breaches to illustrate the severity of the problem.

Yahoo (Aug 2013) 3 billion accounts leaked
Alibaba (Nov 2019) 1.1 billion user data leaked
LinkedIn (Jun 2021) 700 million user data leaked
Sina Weibo (Mar 2020) 538 million accounts leaked
Facebook (Apr 2019) 533 million user data leaked
…

Sadly this is just a scratch of the top of the iceberg. Probably there’s a breach happening right now and the list will never end.

In this conference you will learn a lot about FIDO2. I’ll leave it’s details to other speakers. If you want to know more I’d recommend you to visit the https://fidoalliance.org/fido2 website.

Source Example

package com.example.webauthn;

import io.vertx.core.AbstractVerticle;
import io.vertx.core.Promise;
import io.vertx.core.http.CookieSameSite;
import io.vertx.core.http.HttpServerOptions;
import io.vertx.core.net.JksOptions;
import io.vertx.ext.auth.webauthn.RelyingParty;
import io.vertx.ext.auth.webauthn.WebAuthn;
import io.vertx.ext.auth.webauthn.WebAuthnOptions;
import io.vertx.ext.web.Router;
import io.vertx.ext.web.handler.*;
import io.vertx.ext.web.sstore.LocalSessionStore;

public class MainVerticle extends AbstractVerticle {

    @Override
    public void start(Promise<Void> start) {

        // Dummy database, real world workloads
        // use a persistent store or course!
        final InMemoryStore database = new InMemoryStore();

        // create the webauthn security object
        WebAuthn webAuthN = WebAuthn.create(
                        vertx,
                        new WebAuthnOptions()
                                .setRelyingParty(new RelyingParty().setName("Vert.x Demo Server")))
                // where to load/update authenticators data
                .authenticatorFetcher(database::fetcher)
                .authenticatorUpdater(database::updater);

        final Router app = Router.router(vertx);
        // parse the BODY
        app.post()
                .handler(BodyHandler.create());
        // favicon
        app.route()
                .handler(FaviconHandler.create(vertx));
        // add a session handler
        app.route()
                .handler(SessionHandler
                        .create(LocalSessionStore.create(vertx))
                        .setCookieSameSite(CookieSameSite.STRICT));

        // security handler
        WebAuthnHandler webAuthnHandler = WebAuthnHandler.create(webAuthN)
                .setOrigin(String.format("https://%s.nip.io:8443", System.getenv("IP")))
                // required callback
                .setupCallback(app.post("/webauthn/callback"))
                // optional register callback
                .setupCredentialsCreateCallback(app.post("/webauthn/register"))
                // optional login callback
                .setupCredentialsGetCallback(app.post("/webauthn/login"));

        // secure the remaining routes
        app.route("/protected/*").handler(webAuthnHandler);

        // serve the SPA
        app.route()
                .handler(StaticHandler.create());

        vertx.createHttpServer(
                        new HttpServerOptions()
                                .setSsl(true)
                                .setKeyStoreOptions(
                                        new JksOptions()
                                                .setPath("cert-store.jks")
                                                .setPassword(System.getenv("CERTSTORE_SECRET"))))

                .requestHandler(app)
                .listen(8443, "0.0.0.0")
                .onFailure(start::fail)
                .onSuccess(v -> {
                    System.out.printf("Server listening at: https://%s.nip.io:8443%n", System.getenv("IP"));
                    start.complete();
                });
    }
}

Trust me! SSL works on native images

Tue, 16 Apr 2019 08:00:00 +0000

Native Images and SubstrateVM, the native image AOT compiler from GraalVM, are the hot topic, almost everyone has build a simple HTTP server. But not many people talk about SSL.

Building an HTTPS server is not difficult. For example this is how you would create a client in Eclipse Vert.x:

WebClient client = WebClient
    .create(
      Vertx.vertx(),
      new WebClientOptions().setSsl(true));

client
  .get(443, "icanhazdadjoke.com", "/")
  .putHeader("Accept", "text/plain")
  .send(ar -> {
    if (ar.succeeded()) {
      System.out.println(ar.result().body());
    }
});

Using SSL is nothing new, in fact I already demoed it at JFall 2018.

However in that demo I was just trusting all certificates. Trust is something we usually don’t do on the web so I’ll now show how you can make the code above run by fully verifying the certificate associated with the site I’m consuming the jokes API.

Step 1

First step we need to enable security services, for this we need to use the extra flag to native-image:

--enable-all-security-services

Step 2

Enabling security services will require that the dll libsunec is available in your path. From a linux distribution of GraalVM copy the file:

cp $GRAALVM_HOME/jre/lib/amd64/libsunec.so libsunec.so

This will allow you to use SSL/Security functions. But the application will still not run:

Caused by: io.netty.handler.codec.DecoderException:
    java.lang.RuntimeException: Unexpected error:
        java.security.InvalidAlgorithmParameterException:
            the trustAnchors parameter must be non-empty
...

Step 3

All functions are in place but the application will fail to run because the certificate cannot be verified, now it seems that the final native images will not look to the system root certificates (the ca-certificates package in many distributions) or sometimes the format is not recognized (should be PCKS12). So we need to copy that too from GraalVM:

cp $GRAALVM_HOME/jre/lib/security/cacerts cacerts

Step 4

Yet this won’t work because the files will not be read from the expected location, to solve this we can tell the native image where to read the ca certificate:

./dad-jokes \
  -Djavax.net.ssl.trustStore=./cacerts \
  -Djavax.net.ssl.trustAnchors=./cacerts


A doll was recently found dead in a rice paddy.
It's the only known instance of a nick nack paddy wack.

And voilá it works!

SubstrateVM: Not so fast cowboy!

Thu, 01 Nov 2018 08:00:00 +0000

SubstrateVM, the native image AOT compiler from GraalVM, is one of the hot topics for the java community in the last couple of months. Everyone is excited with small binaries, low resource consumption it brings to the java ecosystem, but is it all true?

I’ve blogged before about native images and how cool they are for serverless, what I haven’t done is blog about using it for performance/cpu intensive applications.

Many people will make the wrong assumption that just because native images are small and compact both on disk space and memory usage they are high performance pieces of software, but lets look at this premise and do some proper research. As you should already know Eclipse Vert.x does work with almost no pain with native images, also, it is one of the fastest low-latency frameworks out there as verified by TechEmpower benchmarks. So let’s look what to expect once you go native.

Setup

First of all, let’s start with the basic benchmark code, you can read all about the official requirements here.

For this example I’ll be using the following dependencies:

io.vertx:vertx-core:3.6.0-SNAPSHOT
io.vertx:vertx-web:3.6.0-SNAPSHOT
io.reactiverse:reactive-pg-client:0.10.5

As usual we start with a verticle (TechEmpower.java):

public class TechEmpower extends AbstractVerticle {

  private final String server = "vertx";
  private String date;

  @Override
  public void start() {
    // will route http paths to benchmark implementations
    final Router app = Router.router(vertx);
    // generate the required value for the date header
    vertx.setPeriodic(1000, handler -> date =
      DateTimeFormatter.RFC_1123_DATE_TIME.format(ZonedDateTime.now()));
    // the postgres client to perform data related operations
    // as required by the benchmark
    PgClient client = PgClient.pool(
      vertx,
      new PgPoolOptions()
        .setUser("benchmarkdbuser")
        .setPassword("benchmarkdbpass")
        .setDatabase("hello_world"));

    // TODO: implement benchmark here...

    // create an HTTP server and bind to a specific port
    vertx
      .createHttpServer()
      .requestHandler(app)
      .listen(8080);
  }
}

Now that we have the boilerplate code in place it is time to add the benchmarks, since I’m not adding a template engine I’ll just implement part of the benchmark, so the code stays small and it is easy to follow, as an exercise you can implement the missing parts.

JSON benchmark

According to the requirements:

This test exercises the framework fundamentals including keep-alive support, request routing, request header parsing, object instantiation, JSON serialization, response header generation, and request count throughput.

app.get("/json").handler(ctx -> {
  ctx.response()
    .putHeader("Server", server)
    .putHeader("Date", date)
    .putHeader("Content-Type", "application/json")
    .end(new JsonObject().put("message", "Hello, World!").toBuffer());
});

Data Access benchmark

According to the requirements:

This test exercises the framework’s object-relational mapper (ORM), random number generator, database driver, and database connection pool.

app.get("/db").handler(ctx -> {
  client.preparedQuery(
    "SELECT id, randomnumber from WORLD where id=$1",
    Tuple.of(randomWorld()),
    res -> {
      if (res.succeeded()) {
        PgIterator resultSet = res.result().iterator();

        if (!resultSet.hasNext()) {
          ctx.fail(404);
          return;
        }

        Row row = resultSet.next();

        ctx.response()
          .putHeader("Server", server)
          .putHeader("Date", date)
          .putHeader("Content-Type", "application/json")
          .end(new JsonObject()
            .put("id", row.getInteger(0))
            .put("randomNumber", row.getInteger(1))
            .toBuffer());
      } else {
        ctx.fail(res.cause());
      }
    });
});

Multiple Queries benchmark

According to the requirements:

This test is a variation of Test #2 and also uses the World table. Multiple rows are fetched to more dramatically punish the database driver and connection pool. At the highest queries-per-request tested (20), this test demonstrates all frameworks’ convergence toward zero requests-per-second as database activity increases.

app.get("/queries").handler(ctx -> {
  final AtomicBoolean failed = new AtomicBoolean(false);
  JsonArray worlds = new JsonArray();

  final int queries = getQueries(ctx.request());

  for (int i = 0; i < queries; i++) {
    client.preparedQuery(
      "SELECT id, randomnumber from WORLD where id=$1",
      Tuple.of(randomWorld()),
      ar -> {
        if (!failed.get()) {
          if (ar.failed()) {
            failed.set(true);
            ctx.fail(ar.cause());
            return;
          }

          // we need a final reference
          final Row row = ar.result().iterator().next();
          worlds.add(new JsonObject()
            .put("id", row.getInteger(0))
            .put("randomNumber", row.getInteger(1)));

          // stop condition
          if (worlds.size() == queries) {
            ctx.response()
              .putHeader("Server", server)
              .putHeader("Date", date)
              .putHeader("Content-Type", "application/json")
              .end(worlds.toBuffer());
          }
        }
      });
  }
});

Plaintext benchmark

According to the requirements:

This test is an exercise of the request-routing fundamentals only, designed to demonstrate the capacity of high-performance platforms in particular. Requests will be sent using HTTP pipelining. The response payload is still small, meaning good performance is still necessary in order to saturate the gigabit Ethernet of the test environment.

app.get("/plaintext").handler(ctx -> {
  ctx.response()
    .putHeader("Server", server)
    .putHeader("Date", date)
    .putHeader("Content-Type", "text/plain")
    .end("Hello, World!");
});

Running the benchmark

When we run the benchmark, in order to take full advantage of the hardware and try to reduce any potential locking we will spawn the same number of CPU cores instances of the verticle. For this we run the following command:

java
    -server
    -XX:+UseNUMA
    -XX:+UseParallelGC
    -XX:+AggressiveOpts
    -Dvertx.disableMetrics=true
    -Dvertx.disableH2c=true
    -Dvertx.disableWebsockets=true
    -Dvertx.flashPolicyHandler=false
    -Dvertx.threadChecks=false
    -Dvertx.disableContextTimings=true
    -Dvertx.disableTCCL=true
    -jar target/benchmark-0.0.1-SNAPSHOT-fat.jar
    --instances `grep --count ^processor /proc/cpuinfo`

Now since native images require a proper main, we can add the following main to the code:

public static void main(String[] args) {
  int instances = 1;
  for (int i = 0; i < args.length; i++) {
    String arg = args[i];
    if ("--instances".equals(arg)) {
      instances = Integer.parseInt(args[i+1]);
    }
  }
  final Vertx vertx = Vertx.vertx();

  for (int i = 0; i < instances; i++) {
    vertx.deployVerticle(new TechEmpower());
  }
}

This will perform the same operation that the vert.x launcher would for the only non JVM specific argument --instances. This way we ensure the same conditions and runtime code is the same in the native image and on the JVM counterpart. We finally build the image with:

native-image
  --no-server
  --enable-all-security-services
  --delay-class-initialization-to-runtime=
    io.netty.handler.codec.http.HttpObjectEncoder,
    io.netty.handler.codec.http2.Http2CodecUtil,
    io.netty.handler.codec.http2.DefaultHttp2FrameWriter,
    io.netty.handler.codec.http.websocketx.WebSocket00FrameEncoder,
    io.netty.handler.ssl.JdkNpnApplicationProtocolNegotiator,
    io.netty.handler.ssl.ReferenceCountedOpenSslEngine
  -Dvertx.disableDnsResolver=true
  -H:+ReportUnsupportedElementsAtRuntime
  -Dvertx.disableMetrics=true
  -Dvertx.disableH2c=true
  -Dvertx.disableWebsockets=true
  -Dvertx.flashPolicyHandler=false
  -Dvertx.threadChecks=false
  -Dvertx.disableContextTimings=true
  -Dvertx.disableTCCL=true
  -jar target/benchmark-0.0.1-SNAPSHOT-fat.jar

As we can see we use the same parameters when initializing the native image heap and we run it as:

./target/benchmark-0.0.1-SNAPSHOT-fat
    -Dvertx.disableMetrics=true
    -Dvertx.disableH2c=true
    -Dvertx.disableWebsockets=true
    -Dvertx.flashPolicyHandler=false
    -Dvertx.threadChecks=false
    -Dvertx.disableContextTimings=true
    -Dvertx.disableTCCL=true
    --instances `grep --count ^processor /proc/cpuinfo`

Just to be sure the same flags are used.

Results

The results are probably what you’re not expecting, I’ve plotted 2 results for the sake of visualization, the JSON test and the data access test:

I must also note that the plaintext tests failed at the highest concurrency ONLY on the native image side with some unexcepted exceptions at the IO stack (however there are no errors when running on the JVM).

So what does this mean? To me, this shows that native images are a powerful feature from GraalVM but they are not the holy grail! Their use case is cli, serverless like applications (as the graal team also says) and they are not really suited (as things stand today) for high performance, long running processes.

Who needs coroutines in Java when there's ES4X?

Thu, 27 Sep 2018 12:00:00 +0000

It has been an amazing week for ES4X with the first results of the Techempower Benchmark showing the polyglot aspect of Eclipse Vert.x as the 4th fastest framework of them all, and the FASTEST using JavaScript.

One of the things ES4X offers is the support for modern JavaScript on the JVM (thanks to GraalVM). So after reading and chatted about the future of Java and the inclusion of co-routines into the JVM with project Loom got me to think:

Why wait for Loom when there’s JavaScript? ¯\(ツ)/¯

Let me explain this a bit further and do a small exercise with the Techempower code. Lets look at the code that fetches a single line of the postgres database and returns it to the client, the initial code is like this:

import {Router} from '@vertx/web';
import {PgClient, Tuple} from '@reactiverse/reactive-pg-client';
import {PgPoolOptions} from '@reactiverse/reactive-pg-client/options';

const SELECT_WORLD = "SELECT id, randomnumber from WORLD where id=$1";

const app = Router.router(vertx);

let client = PgClient.pool(
  vertx,
  new PgPoolOptions()
    .setUser('benchmarkdbuser')
    .setPassword('benchmarkdbpass')
    .setDatabase('hello_world'));

app.get('/').handler(
  ctx => {
    client.preparedQuery(SELECT_WORLD, Tuple.of(1), res => {
      if (res.succeeded()) {
        let resultSet = res.result().iterator();

        if (!resultSet.hasNext()) {
          // no result found
          ctx.fail(404);
          return;
        } else {
          let row = resultSet.next();

          ctx.response()
            .putHeader("Content-Type", "application/json")
            .end(JSON.stringify({
              id: row.getInteger(0),
              randomNumber: row.getInteger(1)
            }));
        }
      } else {
        ctx.fail(res.cause());
      }
    });
  }
);

vertx
  .createHttpServer()
  .requestHandler(req => app.accept(req))
  .listen(8080);

console.log('Server listening at: http://localhost:8080/');

For the untrained java developer eye, there is lots of indentation making it non trivial to follow or read. JavaScript developers are used to this kind of code so, if you’re a polyglot developer it probably won’t hurt your eyes that much to see this…

I Promise it will be easy!

With ES6 JavaScript gained a new type Promise. The Promise object represents the eventual completion (or failure) of an asynchronous operation, and its resulting value. The spec for Promise is quite simple so ES4X has it available even when you’re using Nashorn (Which means only ES5.1 is supported).

Promises will make your code a bit more readable by chaining calls to: then(), catch() and finally() instead of large callbacks and more indentation.

Not so fast!!!

Promises can make your code simpler but remember Vert.x API’s are callback based so this won’t help much (This isn’t entirely true). When creating ES4X the inspiration came mostly from the GOOD practices you see in nodejs, so why not having a system module named util that implements a couple of common features, such as the promisify function?

And that is what you do have already on ES4X, but wait, there’s more! ES4X promisify function behaves in two modes:

when the argument is a function, it behaves just like in nodejs
when the argument is an object, then it wraps each function on the object

So if we were to focus on the previous handler code we could re-write the handler as:

const util = require('util');

app.get('/').handler(
  ctx => {
    // promisified client, methods will return a promise
    // and will not take a callback as the last argument
    let postgres = util.promisify(client);

    postgres
      .preparedQuery(SELECT_WORLD, Tuple.of(1))
      .then(rs => {
        let resultSet = rs.iterator();

        if (!resultSet.hasNext()) {
          ctx.fail(404);
        } else {
          let row = resultSet.next();
          ctx.response()
            .putHeader("Content-Type", "application/json")
            .end(JSON.stringify({
              id: row.getInteger(0),
              randomNumber: row.getInteger(1)
            }));
        }
      })
      .catch(e => ctx.fail(e));
  }
);

This is a bit of a improvement, we traded a small wrapper by code readability.

ES6 is so 2017…

JavaScript world evolves really fast and although ES6 is great, developers have already moved on to ES7! Thankfully GraalVM supports many features of ES7, and the feature I’m really interested now is async-await. The premise is simple:

Within async function(s) you can await for results!

And you can await on… Promises!!! so this means that we can make our code even simpler by using a async function and replace our promise chain with await like this:

const util = require('util');

app.get('/').handler(
  ctx => {
    (async function () {
      // vert.x promise
      let postgres = util.promisify(client);

      try {
        let rs = await postgres.preparedQuery(SELECT_WORLD, Tuple.of(1));
        let resultSet = rs.iterator();

        if (!resultSet.hasNext()) {
          ctx.fail(404);
        } else {
          let row = resultSet.next();
          ctx.response()
            .putHeader("Content-Type", "application/json")
            .end(JSON.stringify({
              id: row.getInteger(0),
              randomNumber: row.getInteger(1)
            }));
        }
      } catch (e) {
        ctx.fail(e);
      }
    })();
  }
);

As you can now read, we’ve flattened out code using the await keyword so the try, catch block is now readable… but there’s a 🤢 in this code, in order to use the await language feature, we must call all our code from an async function, so the whole handler is now wrapped in a async IIFE.

Do we really need it?

The question now is, how can we make things more readable again? and the answer is in front of our eyes. If you pay close attention, the handler function of the router, takes as an argument a closure. A closure in JavaScript is a simple function, so why not make this closure an async one?

const util = require('util');

app.get('/').handler(
  async ctx => {
    let postgres = util.promisify(client);

    try {
      let rs = await postgres.preparedQuery(SELECT_WORLD, Tuple.of(1));
      let resultSet = rs.iterator();

      if (!resultSet.hasNext()) {
        ctx.fail(404);
      } else {
        let row = resultSet.next();
        ctx.response()
          .putHeader("Content-Type", "application/json")
          .end(JSON.stringify({
            id: row.getInteger(0),
            randomNumber: row.getInteger(1)
          }));
      }
    } catch (e) {
      ctx.fail(e);
    }
  }
);

Easy, just add async before the ctx variable and get rid of the IIFE!

Conclusion

With ES4X and GraalVM you can already use all the modern features of JavaScript out of the box, no need to transpilers or compilation steps, on top of that you will have the FASTEST runtime for your JavaScript code and the possibility of using the best of both Worlds (NPM modules and Maven modules), so what are you waiting for to try it out? You can check out the source code for this article here. And of course running it is a simple as:

npm i
npm start

What are you waiting for? :-)

gRPC Vert.x native image? Yes you can!

Tue, 11 Sep 2018 12:00:00 +0000

During the last couple of weeks I’ve been identifying and documenting what it takes to get Eclipse Vert.x applications to work as GraalVM native images. Until now tweaks and fixes are in place to allow developers to use many common components (bellow you’ll see a small subset of this list), So today I’ll be describing gRPC.

gRPC

The best description of gRPC can be seen at wikipedia:

gRPC is an open source remote procedure call (RPC) system initially developed at Google. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts. It generates cross-platform client and server bindings for many languages.

When investigating the code and dependencies of gRPC I was concerned that this could be a complex beast to handle, but I was wrong! Actually everything works.

Bootstrap a gRPC project

In order to simplify your work I’ve a small static website that generates projects for you, don’t worry, it’s a static html app, it all runs on your browser, nothing is sent to servers, all your secrets stay with you.

If you get the same options I have you can go ahead and generate your skeleton project. Once you’ve done this and open the MainVerticle.java file you can start coding your own server. However before we get there we need a proto file. The proto file will contain the description of your API, since this is a lazy example let’s just use the hello world example that you can get with gRPC and add it to src/main/proto/helloworld.proto:

syntax = "proto3";

option java_multiple_files = true;
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";
option objc_class_prefix = "HLW";

package helloworld;

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

As you can see it’s a very simple protocol, there’s a Greeter service that you can use to send HelloRequests and there’s a HelloReply that will contain a message back. Knowing this we can write our own server as:

Vertx vertx = Vertx.vertx();

VertxServer server = VertxServerBuilder
  .forAddress(vertx, "127.0.0.1", 50051)
  .addService(new GreeterGrpc.GreeterVertxImplBase() {
    @Override
    public void sayHello(HelloRequest req, Future<HelloReply> fut) {
      System.out.println("Hello " + req.getName());
      fut.complete(
        HelloReply.newBuilder()
          .setMessage("Hi there, " + req.getName())
          .build());
    }
  }).build();

server.start(ar -> {
  if (ar.succeeded()) {
    System.out.println("gRPC service started");
  } else {
    ar.cause().printStackTrace();
    System.exit(1);
  }
});

As usual one needs to build it:

./mvn -Pnative-image

And you will end up with a 18MB binary.

Writing a client

Of course we’ll need a client too, so here’s what you need:

ManagedChannel channel = VertxChannelBuilder
  .forAddress(vertx, "localhost", 50051)
  .usePlaintext(true)
  .build();

GreeterGrpc.GreeterVertxStub stub = GreeterGrpc.newVertxStub(channel);

HelloRequest request = HelloRequest.newBuilder().setName("Paulo").build();

stub.sayHello(request, asyncResponse -> {
  if (asyncResponse.succeeded()) {
    System.out.println("Succeeded " + asyncResponse.result().getMessage());
  } else {
    asyncResponse.cause().printStackTrace();
  }
});

Testing

From this moment on, all you need to do is run both application and see the output:

server: gRPC service started
server: Hello Paulo
client: Succeeded Hi there, Paulo

Conclusion

I am really impressed with the work the GraalVM and SubstrateVM team has done, in order to support such complex things as the ones I’ve got to work:

vertx
netty
postgres
redis
gRPC
protocol buffers
websockets
HTTP2
etc…

It is still in its infancy but SubstrateVM is showing the full potential of AOT for any kind of short lived java application, be it serverless functions, cli applications, you name it…

Vert.x + Graal = Java for Serverless = ❤️!

Fri, 07 Sep 2018 12:00:00 +0000

As a follow up after the vacations on the post Vert.x native image awesomeness!, I got some Twitter challenge about what about serverles?

This led to a couple of discussions and catching back with some interest on the OpenFaaS project. From here to create a simple template was just a couple of minutes.

So what is interesting about this? Well first the fact that we can use Java as a viable platform to write Functions. Functions are by definition, small units of code and easy to write. Given that Vert.x is a light framework making a function was a piece of cake!

OpenFaaS

From the OpenFaaS site you can read:

Run functions anywhere with the same unified experience - bring your laptop, your own on-prem hardware or create a cluster in the cloud. Pick Kubernetes or Docker to do the heavy lifting enabling you to build a scalable, fault-tolerant event-driven serverless platform for your applications.

The template

In order to run the example and template all you need is to setup your environment and install the faas-cli tool. For this I’d recommend you to read the nice docs on OpenFaaS.

Once the setup is complete we can start playing with Vert.x and Graal as a Function:

Get the template

The first step is to get the template, for this you need to run:

$ faas-cli template pull https://github.com/pmlopes/openfaas-svm-vertx

Fetch templates from repository: https://github.com/pmlopes/openfaas-svm-vertx
2018/09/07 11:59:02 Attempting to expand templates from https://github.com/pmlopes/openfaas-svm-vertx
2018/09/07 11:59:05 Fetched 1 template(s) : [vertx-svm] from https://github.com/pmlopes/openfaas-svm-vertx

You should see some output similar to the listing above. Now that you have the template locally we can create our first function:

$ faas-cli new callme --lang vertx-svm

Folder: callme created.
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|


Function created in folder: callme
Stack file written: callme.yml

As this moment OpenFaaS just created the skeleton project for you, you can inspect it:

tree callme
callme
├── pom.xml
├── README.md
└── src
    └── main
        ├── java
        │   └── MyFunction.java
        ├── resources
        │   └── META-INF
        │       └── services
        │           └── xyz.jetdrone.openfaas.vertx.OpenFaaS
        └── svm
            └── reflection.json

7 directories, 5 files

As you can see it’s a trivial maven project with a single source file MyFunction.java. A close look at the source file you will find the code:

import io.vertx.ext.web.RoutingContext;

import xyz.jetdrone.openfaas.vertx.OpenFaaS;

public class MyFunction implements OpenFaaS {

  public MyFunction() {
    System.out.println("Loaded MyFunction!");
  }

  @Override
  public void handle(RoutingContext ctx) {
    ctx.response().end("Hi!");
  }

}

The constructor is optional so we could make the function even more minimal with:

import io.vertx.ext.web.RoutingContext;

import xyz.jetdrone.openfaas.vertx.OpenFaaS;

public class MyFunction implements OpenFaaS {
  @Override
  public void handle(RoutingContext ctx) {
    ctx.response().end("Hi!");
  }
}

If you were paying attention, there isn’t anything new here, the function is in fact a vertx-web handler, so you don’t need to learn a new framework to get into serverless. But one might ask why the need for a OpenFaaS interface then? The reason is because the entry point application will use Service Loaders to load any available implementations of the marker interface and will add them all to the server.

Build the function

$ faas-cli build -f callme.yml

...

Successfully built f5e1266b0d32
Successfully tagged callme:latest
Image: callme built.

The template will use a Dockerfile that will perform all the heavy work, grab a coffee until you’ll see the message above.

Deploy the function

$ faas-cli deploy -f callme.yml

Deploying: callme.
No existing service to remove
Deployed.
200 OK
URL: http://localhost:8080/function/callme

You can verify it using the web frontend usually running at http://localhost:8080 and it should look more or less like this:

Play with it

Either cURL, httpie or use your browser at http://localhost:8080/function/callme.

http http://127.0.0.1:8080/function/callme
HTTP/1.1 200 OK
Content-Length: 3
Content-Type: text/plain; charset=utf-8
Date: Fri, 07 Sep 2018 12:54:03 GMT
X-Call-Id: a2978cfb-33de-48aa-bc1e-75d370834e87
X-Start-Time: 1536324843677727462

Hi!

Have fun!

Docker stats

So when we start our application and postgres and run docker stats we can see:

CONTAINER ID        NAME                                            CPU %               MEM USAGE / LIMIT
6889f23e814b        func_queue-worker.1.pa37e6ysx20dhfjpcdv9gpite   0.00%               2.496MiB / 50MiB
f9025c9ce3ca        func_gateway.1.qyvg40lzd60o5xez65y3t8rg3        1.34%               8.898MiB / 15.55GiB
a175047e7fe5        callme.1.jbqbp8sd4psz6io1t0uhiq64m              2.49%               7.105MiB / 15.55GiB
40110b24cf82        func_nats.1.7gnn1jpmxe2kepqahrjjdeati           0.06%               5.875MiB / 125MiB
cb00f7c89f32        func_alertmanager.1.kcwlcpm1kmq7gpqvy0t91psxa   0.14%               6.922MiB / 50MiB
ed196726afbd        func_prometheus.1.7vbsnyrytyl9hqu95w8z3ju3d     1.73%               33.34MiB / 500MiB
07dc59c14cf0        func_faas-swarm.1.yeh0xm62rhkebwlhmueqpv47f     0.00%               7.715MiB / 15.55GiB
^C

I’d say that it amazing a complex application running in 7MB of RAM which accounts BOTH for the function AND the watchdog!!!

Vert.x native image awesomeness!

Fri, 10 Aug 2018 12:00:00 +0000

I’ve been working with GraalVM for a while now mostly on the Polyglot aspect, but some work has been done in the native image support. Today I’d like to share what it is possible right now, spoiler: run a Docker image with size of 38MB and 10MB of RAM!

Russian translation of this article is available here.

A bit of history

With the 3.x series of Eclipse Vert.x lots of work was done to reduce the ammount of Classloaders, Reflection magic (this is why there are no annotations, for example). This usually is seen as a contra sense in the java world, but it paid off, as we can already do some amazing stuff without having to thinkering much on hacks or workarounds to circunvent the substrate limitations.

Proof of Concept

As a proof of concept, I’ve decided to build a small application based on a presentation I’ve made about 2 years ago at JavaZone. The application does the following:

Start a WebSocket client to collect in realtime the unconfirmed bitcoin transactions.
Connect to Postgres with the winner of Techempower Benchmarks #16 pg-reactive-client.
On unconfirmed transaction save it to postgres.
On save publish the UTX map-reduced value to vert.x eventbus
Start a HTTP server serve a single page application
On server start bridge the eventbus from the server to the webbrowser using sockjs
On the browser, render the UTX values in realtime as they arrive from the server websocket.

As you can see there is already a lot happening here, servers, clients, websockets, eventbus. I could keep adding more stuff but it’s a PoC right!

Show me the code

Now that we have the idea, we need to implement it, as I said, this was a remake of an old presentation so the code was almost all done for me. This is how it turned out to be:

final Vertx vertx = Vertx.vertx();
final EventBus eb = vertx.eventBus();
final PgPool postgres = PgClient.pool(...);

BlockChainClient.create(vertx)
  .connect(self -> {
    self.subscribeUnconfirmed(json -> {
      postgres.preparedQuery(
        "INSERT INTO UTX (data) VALUES ($1)",
        Tuple.of(Json.create(json)), ar -> {
          int utxValue = 0;
          if (json.containsKey("out")) {
            // reduce step
            for (Object o : json.getJsonArray("out")) {
              utxValue += ((JsonObject) o).getInteger("value", 0);
            }
          }
          eb.publish("data.updates", utxValue);
      });
    });
  });

final Router app = Router.router(vertx);

app.route("/eventbus/*").handler(SockJSHandler.create(vertx));
app.route().handler(StaticHandler.create("static"));

vertx.createHttpServer()
  .requestHandler(app)
  .listen(Integer.getInteger("port", 8080));

Error handling and configuration ommited for brevity.

This is a very simple application and in fact this is exactly how you would code it with Vert.x, I did not do any hack to get it to run on Graal SVM.

Build it

Building the code is trivial, but building the image turned out to have some issues. Luckyly the issues are simple and can all be addressed with a simple substitution java file.

So building the native image was as simple as:

native-image \
  -Djava.net.preferIPv4Stack=true \
  -Dvertx.disableDnsResolver=true \
  -H:IncludeResources="(META-INF/services|webroot)/.*" \
  -H:+ReportUnsupportedElementsAtRuntime \
  -H:ReflectionConfigurationFiles=./src/main/svm/reflection.json \
  -jar "target/bitcoin-viewer.jar"

So what is important to see here, first I specify that I prefer the IPV4 stack from the VM (but this is not really a requirement). Second, I disable Vert.x DNS resolver for the reason that it is not working correctly with SVM and vert.x will fallback to the VM default (blocking) DNS resolver which works fine. I then specify what resources I’d like to keep from my fatjar and specify the substitution file.

Once it completes you can see:

-rwxrwxr-x.  1 plopes plopes 24603024 10 aug 11:45 bitcoin-viewer

Your application is now just 24,6MB!!!

Dockerize it

Graal SVM relies on Glibc so this means you can run it on many images such as ubuntu, fedora, centos… but these images are quite big, so why not alpine?

Alpine images are build against musl-libc and this is an issue. Luckily the alpine project has documented how to get glibc working on alpine and there are already some images on docker hub like frolvlad/alpine-glibc.

So lets convert to docker shall we?

# GraalVM docker image used for AoT compilation
FROM panga/graalvm-ce:latest AS build-aot
# Add maven wrapper
ADD mvnw app/
ADD mvnw.cmd app/
ADD .mvn app/.mvn/
# Add settings.xml to allow snapshots
ADD settings.xml root/.m2/
# Add pom
ADD pom.xml app/
# Add sources
ADD src app/src/
# Set working dir
WORKDIR /app
# Build (java side)
RUN ./mvnw -Pnative-image package
# Build image
RUN native-image \
    --no-server \
    -Djava.net.preferIPv4Stack=true \
    -Dvertx.disableDnsResolver=true \
    -H:IncludeResources="(META-INF/services|webroot)/.*" \
    -H:+ReportUnsupportedElementsAtRuntime \
    -H:ReflectionConfigurationFiles=./src/main/svm/reflection.json \
    -jar "target/bitcoin-viewer.jar"
# Create new image from alpine
FROM frolvlad/alpine-glibc:alpine-3.8
RUN apk add --no-cache ca-certificates
# Copy generated native executable from build-aot
COPY --from=build-aot /app/bitcoin-viewer /bitcoin-viewer
# Set the entrypoint
ENTRYPOINT [ "/bitcoin-viewer" ]

Results

So when we start our application and postgres and run docker stats we can see:

CONTAINER ID  NAME            CPU %  MEM USAGE / LIMIT    MEM %
c7f5e7af56fe  vertx-bitcoin   0.61%  5.133MiB / 15.54GiB  0.03%
a3536684f175  postgres        1.26%  11.27MiB / 15.54GiB  0.07%

I’d say that it amazing a complex application running in 5MB of RAM!!! with instant startup!

And about the image sizes, running docker images we see:

REPOSITORY      TAG      IMAGE ID       CREATED             SIZE
vertx-bitcoin   latest   3b8b487b8ad8   43 minutes ago      37.9MB

So the total size is 38MB!!!

Java is now a viable Serveless technology and a it we can agree that java ain’t slow and bloated right?!

Vert.x Hacks

Secure Vert.x IDE setup

The power of Open-Source

Passwordless FIDO2/WebAuthn 101: Or how to build strong security and stop worry about data breaches

Source Example

Links

Instant Passwordless JVM apps with Vert.x and FIDO2

What’s wrong with the status quo?

Source Example

Links

Trust me! SSL works on native images

Step 1

Step 2

Step 3

Step 4

SubstrateVM: Not so fast cowboy!

Setup

JSON benchmark

Data Access benchmark

Multiple Queries benchmark

Plaintext benchmark

Running the benchmark

Results

Who needs coroutines in Java when there's ES4X?

I Promise it will be easy!

Not so fast!!!

ES6 is so 2017…

Do we really need it?

Conclusion

gRPC Vert.x native image? Yes you can!

gRPC

Bootstrap a gRPC project

Writing a client

Testing

Conclusion

Vert.x + Graal = Java for Serverless = ❤️!

OpenFaaS

The template

Get the template

Build the function

Deploy the function

Play with it

Docker stats

Vert.x native image awesomeness!

A bit of history

Proof of Concept

Show me the code

Build it

Dockerize it

Results