Why Using Camel Was the Right Choice

Around a year ago, we made the decision to write a new API integration layer with Camel. No one on the project had a great deal of experience with Camel, but we completed and deployed the API and it has been running faithfully ever since.

The choice to use Camel was somewhat controversial. It took developers a little while to get accustomed to the DSL syntax, and there were many debates over exactly what the code should look like.

We eventually moved away from Camel for newer API projects, but I recently had to go back and update some of the Camel code. What I found looking at the code a year or so after it was written surprised me.

At the time, thinking in terms of Enterprise Integration Patterns (EIPs) was quite novel. Terms like multicast, recipientList, aggregate, and wireTap were often hard to appreciate, and harder still to incorporate into a process. We persevered, though, and for the most part, we managed to describe the transformation and integration of data with these patterns. It was sometimes frustrating to try and mold our thinking into these EIPs, and I suspect that in large part, this frustration was the reason why we didn’t embrace Camel for future projects.

However, I have to say that reading this code after enough time had passed for me to forget the details was refreshing.

Too often, code is dumped into classes in an imperative train of thought style that makes perfect sense when you are knee deep in a problem and just need to get something working. However, it is so painful to read later on because, without the mental context of the original developer (even if that developer was you), it takes hours to step through each line of code to determine the intent as well as the action.

For all the rough edges we encountered writing a Camel application, being forced to use the common language exposed by EIPs forces you to write much more declarative code. It can take a bit of work to transform your mental model of a problem into the EIP domain, but when you do, the solution will be far easier to understand later on.

I didn’t appreciate it at the time, but describing and implementing a solution with EIPs and the common language that they enforce had more than enough value to overcome the time it took to learn this style of coding. I’m a little disappointed that we discounted Camel for the short term frustrations it brought to our development cycle, but maybe you can learn from my mistakes.