Hi Ramain Thanks for giving the thing a look!
In response to your question: while personally I prefer not to use Spring or CDI there's nothing in K-car that pushes you one way or the other. The service chassis in the MVP (the ready-bake thing you instance and add Routes to via properties file) is camel/servlet-only but there are others planned that will use Spring and other frameworks. The big idea behind K-car is the deeper integration between Maven and Camel to the effect of auto-magickally turning Camel elements, routes, chassis, and services into maven build artifacts that all adhere to a small set of standards so they automatically play nicely with one another. In other words, Camel is already very modular but it, alone, doesn't scale well across an engineering org. Without something like K-car, I, the Principle Eng, can't decompose whatever wonky business logic the product team wants into work I can distribute across my dev teams without dealing with an integration mess at the end of the evolution. A feature and a curse of Camel is that there are a gazillion different ways to do the same thing. As such I'm kindof forced to have the same person handle all the routes for a given service because that's the only way I know for sure that it'll all play nicely with itself. Moreover, without something like K-car setting a paradigm for things like namespacing, it's hard to re-use camel artifacts w/o a lot of cutting, pasting, and snitty re-wiring. Lastly, K-car does the same thing for deployed services that Maven does for project structure. For any given K-car service, I don't have to know anything about a given service to know my way around. This helps enormously with on-boarding new folks as well as ensuring the teams aren't screwed when someone leaves. Because everything is standardized down to the element level, everyone can work on anything in the ecosystem. Yes standards can in theory be enforced via institutional knowledge but in 20 years of doing this I've never once seen a shop disciplined enough to maintain standards w/o the help of frameworks, linters, and automation. As for python - long term my goal is to replace that with a camel-main project that runs a full CLI. Python was a way to get MVP out with some of the maven automation. It's definitely going to be removed in a future release. Nothing against python - it's just that this is a java project and I don't want to force java devs to maintain a python dependency as well. David Holiday On Tue, Jan 12, 2021 at 10:11 AM Romain Manni-Bucau <[email protected]> wrote: > Hi David, > > Did read the readme and browsed (too quickly this is why i asked) the code > but i'm not sure currently what I get compared to camel+cdi/openwebbeans > stack which looks as simple/customizable/flexible and opens the door to k8s > native integrations (from healthchecks, metrics, tracing to native mode > with graalvm). > Any highlights on that? Is the value the python script to help to > bootstrap? (if so it would be great to not require pythong for java dev but > maybe java?). > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mar. 12 janv. 2021 à 17:55, David Holiday <[email protected]> a > écrit : > >> Hello fellow Camel riders! >> >> I made a thing for Camel that makes it dead simple for teams to quickly >> build and deploy prod-ready microservices. The MVP can be found on github >> <https://github.com/davidholiday/kcar>. I'm posting here to ask for your >> thoughts on what works, what doesn't, and whether or not you find it >> useful. >> >> I wrote this because I needed a way to quickly produce Camel services. I >> needed something that encouraged re-use of service artifacts, didn't rely >> on Spring, and could scale in a way that gave me the ability to farm out >> work to other engineers without a lot of 'too many cooks in the same >> kitchen' bs. >> >> I'm sure I'm not the first engineer to have these challenges so definitely >> curious as to your thoughts not only on the merits of this particular >> solution, but also your thoughts and experiences in addressing them. >> >> cheers (and ty!) >> >> David >> >
