Vertx implementation

[okta]

Vertx implementation

[idontusenumbers]

Vertx uses async IO, this library, as it stands, does not. Async IO allows for MUCH better scaling. To use this library with a vertx application, one must wrap all the calls to the jwtverifier in special blocking wrappers. This reduces the scalability of an application that uses the okta jwt verifier.

[bdemers]

Thanks @idontusenumbers! The goal of this lib is to allow integrations into any other lib/framework. I haven't used vertx, but if there something blocking this let us know!

Also, other feel free to comment on this issue even after it is closed, we will keep watching for interest!

[kbobrowski]

Hi @bdemers , indeed it'd be nice to have async verifier, currently when using it from vertx I have to wrap this in executeBlocking which does not scale well. Async version would also integrate with Kotlin coroutines, which may be interesting for Android developers

[bdemers]

@kbobrowski while, not perfect, the only blocking IO call should be when a new public key is requested, which IIRC is once a quarter.

Can you tell me a bit more about your Android use case?

[kbobrowski]

@bdemers that's right, it will block for longer time very rarely when getting new public key. But if I wrap decode(token) in executeBlocking to account for this, then during each API call the server would have to reserve new thread from thread pool, verify it in this thread, and return result, instead of doing this on the main event loop - not sure about performance penalty here at the moment. I guess intermediate solution specifically for vertx would be a flavor of decode which can also accept Handler<AsyncResult<Jwt>>, and which internally would use separate thread only for blocking IO (or ideally using non-blocking web client). But not sure how large the audience is for such solution, I can work around this at the moment I think :)

Regarding Android - currently I use verifier only server-side, but I can imagine that async verifier could be useful there as well

[bdemers]

This is helpful, I wasn't thinking about the added overhead of the wrapping of the method call