Kikaha Philosophy

Kikaha Philosophy

Man cannot discover new oceans unless he has the courage to lose sight of the shore.

Quite often we hear a sales man talking about innovation, how his company will delivery a new version of a software bringing up a huge set of features that will change the way the industry will perform its daily tasks. But a wise developer will take a look into that software and see that the innovation the seller was talking about was just a few buttons that shows new windows. We all know that innovation isn't about offer new features, but a create an experience that really solves the end user's problem.

In 2013, we was engaged to rewrite a legacy C socket server that acted as communication layer to an even more legacy code written in Cobol. The team involved with the project was Java developers and, as should be, names like Tomcat, Jetty and Wildfly come to our mind. Even Play Framework was a possibility at time. After some research and analyzing our hardware limitations we ended up choosing Undertow as basis to our development.

Simple, with low footprint and extremely fast, it performed amazingly under heavy load in production. As the software grew we automated the primary Undertow's APIs. Earlier in 2014 we had opened the source code of these automated parts. Originally named as Undertow standalone it was renamed to Kikaha and incubated at Skullabs.io.

Keep the complexity low

We believe that most of developers need a convention to follow while developing a software. This allow them to perform more focused, once they do not have to define a design to its entire software.

One thing that makes Undertow unique is that it has no concept of a global container. Instead an Undertow server is assembled by the embedding application. This makes Undertow extremely flexible, and the embedding application can basically just pick the parts that they need, and assemble them in whatever way makes sense.

Undertow intent to be more generic and it make sense, specially to JBoss Community, where it behave as basis to Wildfly, the most important Open Source JEE container. Kikaha, in other hand, was designed to bootstrap Undertow transparently, automatically deploying routes with no repetitive start up routines. One of our main goals is to cover all Undertow API, and then, complex configurations like this one will be totally optional.

Really low footprint

While most of Java containers consumes a lot of RAM and takes up to 200Mb of disk space, a simple Kikaha application uses less than 5Mb of disk space and consumes near to 10Mb of RAM under average load. We have a heavy load application delivering up to 100K requests per second taking slightly more than 700Mb of RAM.

A clean code server for clean coder developers

We know there is a lot of work to make Kikaha's code even more cleaner, but we believe we did a great job providing a nice well crafted API. We follow Uncle Bob's SOLID principles wherever is possible and make a great effort keeping our code coverage very close to 75%.

We expect developers will be at home whenever a developer needs check the source code to find any gap our documentation does not provide.

And modularity for the rest of us

The software will grow as developer needs grows. We developed a tiny core and provide extensions in a plug-and-play fashion: no configuration lines of code needed.