Apache Camel’s time is now officially over.
Use Node.js with Express.js instead, you will be glad you did. Node is fun and easy. Camel is the opposite.
My working experience with Camel: five months at a company that uses Camel, given a new project and told to implement with Camel.
Working experience with Node: developed an interactive website as a learning project, plus a project to run Google Puppeteer to automate hitting a website to download and email PDFs.
Full disclosure: since the very first second I came across a “framework” I have hated them. Always will. Libraries are awesome. Frameworks suck ass.
Camel’s problems (all solved with Node):
- No debugging. Okay some of your program can be debugged, but the core of any Camel program is the route definitions part, which lives in a configuration method invoked only at start-up. So you can’t place (useful) break points in the core of your program. For me that is enough of a downside to never, ever, consider using this framework. In practice it has been an awful experience to find and fix problems. It is necessary to add extra logging and other debug code (I have a bean that dumps the current state to the console).
- Broad yet shallow, uninsightful documentation, 2 stars out of 5. Reads like it was written by a bot (and not a good one). Node’s documentation is just better, explains things well, 4 out of 5 stars. Part of what makes Node’s documentation so much better is you don’t have to change your thinking to understand it.
- Awkward “framework” code. Writing a simple if/else results in goofy code with “choice”, “when”, and “otherwise” keywords. Looping uses “split”, if your lucky. It can be awkward to just control the program flow.
- There is a message “body” that you need to implicitly keep track. You can’t just read the code, you have to carefully inspect it to see if the body changed somewhere without someone leaving a comment (there are no variable declarations or typed parameters). In Node what do you do? Just read the code, nothing mysterious.
- Strings and more strings. Much of defining routes in Camel requires passing strings to methods, sometimes large strings, a hundred or more characters. Strings which are not checked at compile time, like they would be in other languages (like Typescript, which I use with Node). One tiny typo in one of these strings can cause the configuration call to fail at program start, with an annoying vague exception about a route not loading. Database calls are particularly a problem (and especially poorly documented to boot).
Nuff said.
