Apache Camel w 2021 roku

Co sądzicie o tej technologii? Widziałem niedawno temu jakiś nowy projekt i byłem przerażony tym jak bardzo utrudnia to jakiekolwiek rozumowanie o kodzie, gdzie wszystko opiera się na słabym typowaniu i programowaniu w stringach

Jedni powiedzą że Camel jest super, bo można tam ogarnąć wszystko, requesty do usług, kolejkowanie, żonglowanie danymi itp. Mi się jednak kojarzy głównie z programowaniem w XSLT i nie chciałbym do tego wracać. Jak z każdym narzędziem, można uzyskać kupę, jeśli na przykład opiera się całą logikę na transformatach.

Idiotyzm, na który niestety dosyć często trafiam w pracy. Może miało jakiś sens 100 lat temu (wątpię, ale może...), ale aktualnie to bardziej utrudnia pracę niż pomaga. Pierwsze lepsze problemy, które mi przychodzą do głowy:

• Zamiast zaprojektowania klasy z danymi potrzebnymi w procesie wrzuca się wszystko do headerów i body typu Object, bo generyków żadnych tam nie uświadczymy. Potem kod jest najeżony jakimiś ciągłymi rzutowaniami body i headerów.
• Stan obiektu zmieniamy getterem, to oczywiste exchange.getIn().setHeader("header", value)
• Programowanie w stringach - wszystko przekazujemy jako jakieś magiczne stringi: scheduler, endpoint ftp, zapięcie metryk - po raz kolejny tracimy zalety typowania, ale już zaczynam się przyzwyczajać, że Javowcy po prostu nienawidzą typowania i najchętniej wszystko by pisali w stringach i YAMLach (kiedyś XMLach).
• Odnośnie metryk - nie tak dawno właśnie to robiłem w aplikacji Camelowej. Normalnie mi by to zajęło jakieś 30 sekund w kodzie napisanym po ludzku. myProcess() zamieniłbym na processTimer.record(() -> myProcess()) i po kłopocie - czas procesu zmierzony. W Camelu niestety musiałem uzyć specjalnego modułu integrującego się z Micrometerem, ale przestarzała wersja Camela nie obsługiwała tego modułu. Long story short, musiałem podbić wersje wszystkiego w aplikacji i z 30 sekund zrobił się dzień pracy. Oczywiście metryki wyglądają jak g***no, bo zintegrowane jest w Camelu to na bazie jakiś haxów dostosowujących się do istniejącej składni Camela.
• Zamieniamy proste i oczywiste konstrukcje językowe jak np. if/else na jakiś absurdalny dsl.
  Przykład: if(something.size() > 0) zamienimy w Camelu na .choice().when(simple("${body.something.size()} > 0")). Jedyny komentarz jaki się nasuwa to: XD.

To jest typowa korporacyjna technologia, która nie wnosi żadnej wartości dodanej, generując przy okazji masę niepotrzebnej pracy i problemów konfiguracyjnych. Jak najdalej od tego typu rozwiązań. Piszmy normalny kod, zamiast bawić się w jakieś stringowe konfiguracje. Póki co jest to jedna z najgorszych technologii, z którymi miałem styczność. Nie dlatego, że jest taka tragiczna w wykorzystaniu. Tylko dlatego, że nie rozwiązuje praktycznie żadnych problemów, a przy okazji tworzy bardzo dużo nowych, wprowadza chaos i trudność debugowania. Apache Camel stoi dla mnie zaraz obok (nowo)tworów pokroju Camundy.

CAMEL do integracji na nie, ok rozumiem. Zawsze wydawało mi się (i nadal tak jest), że to takie ustrojstwo na pograniczu "naszego" systemu, które ma ułatwić integrację z innymi, a nie element, wokół którego buduje się aplikację.

Jak zatem robicie integrację z innymi systemami?

Nie mówię tu o trywialnych przypadkach typu "wołam 1 web service/wystwiam 1 web service", ale integrację w środowisku, które jest bardzo zróżnicowane jeśli chodzi o technologię i interfejsy wystawiane przez różnej maści 3pp ("3rd party providers"). Chyba, że wszyscy już na "nowoczesnych" technologiach (Spring edycja 2050? ;) )

@yarel: problemem jest fakt, że Camel wymusza na tobie użycie ich dziwnego DSLa, więc jak chcesz cokolwiek zrobić, to jesteś zmuszony oddać swoją aplikację w ręce Camela. Możlwie, że da się to zrobić w ładny sposób, że używasz Camela tylko dla integracji, ale wszystkie projekty jakie widziałem były mocno z nim związane. Zresztą podobnie wygląda to w innych reaktywnych technologiach np. WebFlux, tylko tam masz typy i zerową ilość stringów.

Niestety miałem z tym styczność i mnie szlag trafiał od zawsze na to g.