5 ms·

Ask HN: Am I the only one who thinks Apache Camel is awful?

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. I'm sure some will say it depends on how you use it, but the "features" that create the aforementioned problems seem to be what most people tout as the benefits of Camel (e.g. "flexibility"). What am I missing?

davelnewton 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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. :)

davelnewton 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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. :)