Many developers these days don’t have to write a client library/driver from scratch or ever have to Just Open A Socket. Normally, they’re going to use an HTTP client or a driver/library provided by the database/whatever. I happen to be the exception; my job at the moment revolves entirely around creating those drivers for Riak.

I’m probably the Worst Java Guy Evar in that … I’m not a Java guy. At least, not what you think of when you hear “Java guy”. I’m a polyglot forged with C who happened to have fallen into doing some Java dev once and then at Basho became … the Java guy.  In short, I’m not a big fan of including a giant framework in a project to do some stupid simple task. Or shoehorning problems into design patterns because … reasons. I also have a tendency to want to hit something every time I hear the word “Spring”.

That said, when designing the new Java client for Riak, rather than writing the networky bits myself I thought maybe I’d take a look at Netty. I’d heard good things about it and thought maybe it’d be a good fit if wasn’t overly cumbersome. We (Basho) also had some customer interest in providing async query functionality in the client which I knew Netty could provide.  In addition … lets face it, there’s nothing enjoyable about writing socket code for the umpteenth time.

After playing with the Netty 4 for a bit I decided on using it for the new Riak client. Not only did it provide what we needed, I found Norman Maurer at Redhat to be incredibly helpful and a real advocate for what they were developing.

The internals of the new Riak Java client effectively will model a Riak cluster, providing load balancing and fail-over support. It also allows for both synchronous and asynchronous operations. The higher level client API will submit tasks to it and receive the replies.

Over the next couple weeks I’ll be posting a series of articles talking about how to use Netty to build a network client library. First one coming soon.