We're using the ClientSideSessionsModule for our SessionStorage implementation. Consequently we don't get any benefit from the change of SessionStorage to a Promise based API. I'm trying (and currently failing) to put a synchronous wrapper around it to save us the hassle of handling callbacks higher up the stack, but I can't work out how to block and synchronously retrieve the result of a promise; the equivalent of calling Future.get() in Java land. Is this even possible?
The motivation for wrapping Session interactions in Promises is to provide a consistent API regardless of the backing implementation. It's more the rule than the exception that backing session stores would be I/O heavy.
I don't believe it's possible to block on a value unless you're in a `ExecControl.blocking` or `Promise.blockingMap` call.
Ratpack is a sharp departure from the traditional Servlet container based frameworks in that it's asynchronous, non-blocking, and reactive from the ground up. This means the entire framework is designed to facilitate a functional reactive approach to handling web requests. This makes it a lot easier to compose various components provided by Ratpack and Ratpack modules. Granted it takes a while to switch to this way of thinking from traditional blocking Servlet approach but when the lightbulb turns on it's very rewarding.
If you're dead-set on blocking, then you can do it with Ratpack's RxJava integration. Convert the Promise to an Observable and use a BlockingObservable to synchronously get your data out.
That said, I'll echo everything Danny has said. One of the ways that Ratpack achieves throughput of over a half million req/s is through an efficient resource footprint, supported by NIO and a small thread pool. If you block in a request taking thread, then it will not be available to satisfy subsequent requests, meaning that your throughput will drastically suffer.