Upgrade Vertx to 4.x

[alexellis]

Upgrade Vertx to 4.x

Expected Behaviour

We should have an option or change our main option for java11-vertx that means users can take advantage of the latest stable version of the Vertx framework

https://vertx.io/docs/vertx-web/java/

Current Behaviour

Still using 3.x

List All Possible Solutions and Workarounds

• Change the template java11-vertx to just use the new library 4.x
• Add a new template named java11-vertx4 with the new library 4.x
• Do nothing and let users fork / maintain their own templates

Which Solution Do You Recommend?

I prefer 1 for its simplicity, and I was able to change the entrypoint and it just worked.

However, @pmlopes (Vert.x maintainer) tells me that there are breaking changes in 3 -> 4, that could affect some users. I am not sure what those are and do not have examples. They do not affect our hello-world app.

Steps to Reproduce (for bugs)

1. Create a new function
2. Navigate to the Vertx docs and see invalid instructions because they are written for v4

Context

An OpenFaaS Pro customer is using this template and has forked it to update the Vertx version, and I've had several calls with other prospective customers who have expressed an interest.

[pmlopes]

For the "next" version I'd propose a change to the original interface:

public interface FaasFunction<T> extends Function<Future<T>, RoutingContext>> {

  default Future<Void> setup(Router router) {
    return Future.SucceededFuture();
  }
}

This means that user only need to do:

public class MyFunction implements FaasFunction<JsonObject> {
  // if a user want to make use of other vert.x handlers, for example, BodyHandler ,JWTHandler
  // just override the setup method, otherwise it is not needed as it is a default method
  public Future<Void> setup(Router router) {
    router.route().handler(BodyHandler.create());
    return succeededFuture();
  }

  // here is the function
  public Future<JsonObject> apply(RouttingContext ctx) {
    return succeededFuture(new JsonObject("hello", "world"));
  }
}

The choice of using a function allows the entrypoint to use the respond method which will ensure you don't need to worry about encoding json, binary or text manually. It also implies that the request is complete, using a handler this isn't guaranteed as the api assumes the call can continue.

The setup phase is optional, so users can use it to add features, for example it can allow us to remove the STATIC file handler and webroot from the template as it is now up to the user to decide how it works.

A second optional method could be added to do shutdown() if this is needed. Like when the whole container is stopped gracefully some code is executed.

[pmlopes]

For reference: https://vertx.io/docs/vertx-web/java/#_simple_responses

Using this new API has many benefits to end users, such as, better error handling:

.respond(rc -> {
        throw new RuntimeException("Boom!");
      }

Will now be catched and returns either a 500 error, or if during setup a custom error handler is mounted, than that handler will process the error.

It also allows composition, for example, using a client like redis to query the database and return the future of that call directly:

return redis.send(HGETALL, "my-key");

In this case the response from the call is converted acording to the rules of respond. If the rules are too simple, then using future composition, e.g.:

return redis.send(HGETALL, "my-key")
  .map(response -> ...);

Can be used to convert from a non supported type to a web safe type (json, buffer, string)...