CamelBee Logo

About CamelBee

The problem

Starting an Apache Camel microservice is not hard. Starting one that is actually finished is. The routes are the easy part; what takes the week is everything around them — the mappers between model layers, the Docker Compose file that stands up a Kafka and a Postgres, the integration tests that prove the backend really received what you sent, the black-box tests that run the whole thing end to end, the native build configuration. Most projects ship with some of that and an intention to add the rest later.

AI coding tools made this sharper rather than easier. An assistant given an empty directory invents its own architecture, its own test patterns and its own idea of how to mock a message broker — slightly differently every time. Given a working, opinionated project, the same assistant extends what is already there.

What CamelBee does about it

CamelBee generates the finished version. You choose the interfaces your service exposes and the backends it integrates with, and you get a Spring Boot or Quarkus project with the routes, models, mappers, configuration, containers, and unit, integration and black-box tests that pass before you have written a line. The test infrastructure is written once per technology and reused, which is why a project with Cassandra and Kafka in it arrives already knowing how to test Cassandra and Kafka.

Your AI tool then inherits a working reference implementation and a set of rules for how the project fits together, so it adapts rather than invents. The embedded debugger shows messages moving through the routes at runtime, so you can review what was built by watching it run instead of reading every line.

Who builds it

The framework libraries are open source on GitHub; write-ups are published on Medium. Questions and requests are welcome — see the contact page.