
Ask HN: Am I the only one who thinks Apache Camel is awful? - unclebucknasty
Everywhere I look online, people seem to rave about Camel. But, to me it seems an awful mish-mash of disjointed technologies and languages that make simple problems hard and hard problems painful. It is difficult to debug, does not particularly lend itself to re-usable solutions, and generally obfuscates what could otherwise be fairly clean integrations and makes them ugly.<p>I&#x27;m sure some will say it depends on how you use it, but the &quot;features&quot; that create the aforementioned problems seem to be what most people tout as the benefits of Camel (e.g. &quot;flexibility&quot;).<p>What am I missing?
======
davelnewton
Not sure. Camel allows working with multiple transport technologies and
normalizes them to a single API. It doesn't _implement_ those multiple
technologies.

If it doesn't solve the problems you have then it probably _does_ seem
complicated--but it solves a certain class of complicated problems reasonably
well.

Let's flip the question on its head: what should people use instead?

~~~
unclebucknasty
Hmm. Seems like it does implement many transport technologies: HTTP, FTP, etc.
It also seems to encourage processing of raw requests/responses via
XSLT/XPath, etc.

Anyway, I'm not familiar with alternatives like Mule, but visual tools do seem
to be in order for complex integrations.

But, I am not 100% sure that people "should use" anything, per se. The promise
of RESTful interfaces, SOAP, and other integration approaches was to allow
code/objects to be used and semantics imposed per domain/use case, not to
treat them as declarative, agnostic data exchanges.

So, I'm not sure why we need much more than good old coded logic and transport
libraries when it's time to hit the wire.

But, this mish-mash of declarative routing XMLs, DSLs, etc. just feels hacky.
Instead of just writing the integrations in code, I now have this added layer
to manage. And, I don't know what I'm getting for it in return.

~~~
davelnewton
The transport technologies already exist; Camel unifies them under a single
API. What you get in return is precisely _not_ having to manage all of them in
your own code.

Simplistic problems don't demand complex solutions. Complex problems do. If
you're not doing anything complex enough to require a complex solution, then
of course you wouldn't need something like Camel or any other ESB-like
solution.

¯\\(°_o)/¯

~~~
unclebucknasty
Sure. I'm saying that Camel doesn't seem to provide what's advertised for
those complex cases. Instead, it adds a layer of obfuscation and more
constructs to manage to what could otherwise be clean code.

I think we just disagree on that point, as I apparently do with everyone
regarding Camel.

But, I don't fret. I also thought J2EE was completely nuts when everyone still
believed it was the new sliced bread. :)

