jooby 3: next major release

[jknack]

This is an open discussion of what we want for Jooby 3.x. For now we will start a discussion here and then cleanup ideas/features to a wiki page (or similar).

Beside is going to be a major release... I'm not planning to break compatibility like we did in 1.x -> 2.x upgrade, so:

• Web site will keep as it is today: https://jooby.io, same goes for Java package: io.jooby.
• The 3.x source code will be just a refactor of existing 2.x source code (not an entire rewrite). Unless something really bad/ugly come up, you will be able to upgrade doing a search/replace session.

Some notes I have so far:

• Review Context API add getter/setter for almost everything (simplify unit test)
• Keep minimum request/response related method into Context (simply context API)
• Add getRequest/getResponse method to Context and add all the necessary getter/setter to each of these new Request/Response API
• Remove bytecode analysis for return types and get back reactive operators (similar to 1.x)
• Remove asm from jooby core
• Kotlin Normal route vs Coroutine route try to simplify usage and remove the HandlerContext object. Favor usage of fun some(ctx: Context) and then get("/route", ::some). This probably implies that lambda body route are bind to Context itself
• Rename FileUpload.destroy to close and make it Closable
• Value API make them getter friendly
• Remove runApp. Replace. with new App()
• Rename Jooby class to WebApp?
• Use application.logback.xml so we don't have initialization issues

As always, your feedback is welcome

[sayyiditow]

These look good. Can you also include adding of setter methods for the ModelAndView class so we don't have to re-initialize the class in case we are changing the view name for the same route?

Having to do this right now, in stead just set the view name based on the request parameters. Other routes can have multiple such initialization which looks expensive?

get("/", ctx -> {
            ValueNode asyncPage = ctx.query("asyncPage");
            ModelAndView modelAndView;
            if (Boolean.parseBoolean(asyncPage.toString()))
                modelAndView = new ModelAndView("index_async.ftl");
            else
                modelAndView = new ModelAndView("index.ftl");
            
            return modelAndView;
        });

[imeszaros]

Nice to hear that compatibility with 2.x is kept in mind. We just started to use Jooby 2.x and planning with it for the long run, also planning to migrate our older codebases.

Huge thumbs up for the API refactoring for Contect -> Request + Response!

We ran into some problems with the Guice extension. In Jooby 1.x it was very convenient that you could inject request scoped objects into controllers / services. In Jooby 2.x it's only possible with some custom extensions implementing @RequestScoped and co. similarly to Jooby 1.x.

Could you briefly explain what does return value analysis and ASM in Jooby do?

[jknack]

Huge thumbs up for the API refactoring for Contect -> Request + Response!

Going to keep Context in 3.x, because feel it is better the single argument handler:

get("/", ctx -> {...})

and not the two arguments

get("/", (req, rsp) -> {...}

There are some method name collision will keeping everything in Context class. In 3.x going to only keep the most frequently used methods in Context class, while less frequently or more specific methods will be available in Request/Response classes. This helps to keep some common code in Context (jooby-core) and force server to implement more simple/basic Request/Response objects.

Could you briefly explain what does return value analysis and ASM in Jooby do?

ASM helps to identify handler return types in lambda/script routes:

get("/rx", ctx -> CompletableFuture.supplyAsync(() -> "..."));

So here ASM find the handler returns a completable future and:

• Run route handler in EventLoop
• Attach a completable listener and to send response when ready

Same for other reactive types from: rxjava and reactor
In 3.x this will requires some manual intervention (like in 1.x):

use(new CompletableFutureAdaptor());
get("/rx", ctx -> CompletableFuture.supplyAsync(() -> "..."));

Removing ASM give us:

• Even faster startup time
• Reduce memory in class space

[re-thc]

Would removing ASM slow performance down?

Would be good to add a jackson alternative such as dsljson since that's been 1 of the bottlenecks in techempower benchmarks :)

Maybe other security options besides a heavy weight like pac4j?

GraalVM aka native mode would be useful in a lot of places but might be a bit of work.

[jknack]

Would removing ASM slow performance down?

A bit on some specific use cases, but not for usage on real application.

Would be good to add a jackson alternative such as dsljson since that's been 1 of the bottlenecks in techempower benchmarks :)

Yea, nothing stop us from using dsljson today. Due it requires an annotation processor, don't think we need to support as Jooby module. I keep jackson in TEB bc is a real library that works for complex use cases. Still, we. could rewrite the benchmark to use. something more lightweight

Maybe other security options besides a heavy weight like pac4j?

Hahaha, feel something similar... but is there any security framework lightweight?

GraalVM aka native mode would be useful in a lot of places but might be a bit of work.

We did some work and got something working with 2.x, slf4j-simple logging and netty (think undertow didn't work). Removing ASM from core (actually from runtime) will help to make Graal image.

[re-thc]

Yea, nothing stop us from using dsljson today. Due it requires an annotation processor,

dsljson has a reflection option, which is still quite a bit faster.

but is there any security framework lightweight?

If it's just basic auth or jwt (via e.g. jjwt) then it doesn't really need a "framework".

netty (think undertow didn't work)

Undertow 3 will be a wrapper around netty.

[jknack]

dsljson has a reflection option, which is still quite a bit faster.

cool, I didn't know it.

If it's just basic auth or jwt (via e.g. jjwt) then it doesn't really need a "framework".

Yea, I usually do header auth so never use pac4j. There is a jwt auth module too: https://jooby.io/modules/jwt-session-store/

Undertow 3 will be a wrapper around netty.

Awful/wrong decision is you ask me. Found undertow super fast (faster than netty) and by far lot easy to work than netty. Also, it is a truly option/alternative to netty today. Don't want to be a wrapper over netty.
I believe Undertow API and execution model will be more or less the same (but around netty). Probably going to drop support for Netty when Undertow run on top of it.

[re-thc]

Found undertow super fast (faster than netty)

Depends. Netty has more features like OpenSSL support. There's a lot of options that can be turned on. Out of the box Undertow is faster. Netty is complex though I agree.

Awful/wrong decision is you ask me.

Main focus is on moving off Wildfly (the main use of Undertow) and into Quarkus (which is Vertx/Netty). Makes sense as a business - Netty has a lot more users in the community, e.g. Twitter, Google and Apple. I don't think it's wise for IBM to be re-implementing HTTP3 and many of the other missing features in Java land when it comes to it so consolidating was a good move.

Undertow hasn't had major features properly in a long time. It was almost a solo project and the ex-lead now moved to Quarkus. I really like the API of Undertow!

Probably going to drop support for Netty when Undertow run on top of it.

Would be good to compare once Undertow 3 or 4 comes out to see how much overhead they've added too.

There is a jwt auth module too

Is it a documentation issue? The session store doesn't feel like authentication so maybe I'm misunderstanding it...

Simple caching with annotations and some assistance with API versioning would be good too.

[jknack]

I'm not going to say anything about Quarkus... 😄

Is it a documentation issue? The session store doesn't feel like authentication so maybe I'm misunderstanding it...

Integrates the HTTP Session with JWT token using a cookie or header.

Simple caching with annotations and some assistance with API versioning would be good too.

Yea, this is more or less: module (so we can probably add something today). This thread is more for core changes. Do you have an example of API versioning?

[re-thc]

Do you have an example of API versioning?

@Version(1) -- so via annotations on methods / classes and option to set it as either via header, request parameter, or part of the uri to request it. Can return via uri, mime type or header etc.

[inaiat]

kotlinx.serialization support!

Would be great to see some native support for https://github.com/Kotlin/kotlinx.serialization

Thanks!