vert.x removal

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

vert.x removal

laphroaig
I came across vert.x when I was casting about for a lightweight framework to support a simple, embeddable, groovy compatible JSON over HTTP with maybe a few HTML pages and forms (i.e. Gaelykish sans Google).  I saw the article (http://ldaley.com/post/42018685081/jetty-or-vert-x-for-ratpack) where a cryptic message says that you ditched vert.x for Netty; its underlying library.  My very superficial embedding of the vert.x libraries w/o platform seem to work.  I was wondering if you could elaborate on the reasons for your switch.  I don't have a dog in the hunt, but I'm trying to better understand the various projects and their overhead versus value add.

cheers,

-Jess
Reply | Threaded
Open this post in threaded view
|

Re: vert.x removal

Luke Daley
Administrator
Hi,

This was about 18 months ago so everything may have changed. There were two main issues that caused me to abandon Vert.x.

Vert.x binds all segments of a logical execution to a single thread. Some code expects this to be the case. When you embed Vert.x you have to do this yourself.

Secondly, in the HTTP server support you have to decide whether you want the request body or not before the handler returns. This means that you can’t do an async read of the file system to check for a file before reading the request body. That was an indication to me that non blocking wasn’t fully supported and turned me off. As I say, this could very well have changed by now.

There were also issues with using modules when embedding because the module bootstrapping API was private. 

Also, it was just more than I needed for Ratpack and in the end didn’t offer enough benefit over using Netty directly.