Apache Camel - amuradon/trader-journey GitHub Wiki
Tak nějak mám pořád pochybnosti, jestli používat Apache Camel nebo ne. Chci si to shrnout pro a proti. Nějaké srovnání už jsem si dělal na https://github.com/amuradon/pumptrader/wiki/Decision-%E2%80%90-integration-framework
Bez Camel
- (-) některé věci naimplementovat sám
- (+) vše pod plnou kontrolou
- (+) jednoduchá implementace
- (+) jednoduchý debugging
- (+) není se co učit
- (+) jednoduché testování
- (+) jakákoliv architektura
- (+) rychlejší aplikace
Apache Camel
- (+) podporuje spoustu věcí out-of-box - EIP, integrace
- (-) není jednoduché se naučit, celkem mě to zdržuje
- (-) hodně nepřehledných abstraktních vrstev
- (-) složitý debugging
- (-) dokumentace sice dobrá, ale neúplná a zmatená
- (-) složitá implementace, kolikrát trial-n-error (např. jednoduchý if nebo 2 nezávislé HTTP cally přes multicast a aggregation!)
- (-) složitější testování
- (-) nutnost implementace v message routing architektuře - složitá komunikace a sdílení dat mezi routy
- (-) zpomaluje celou aplikaci
- (-) potenciální bugy (např. vertx HTTP client)
- (-) neustále přetypování - obrovský prostor pro bugy
- (-) DSL je v podstatě nový jazyk a to poměrně nepovedený
- (-) Programování ve Stringu (URL, simple, OGNL)
- (-) Omezen jejich výběrem library (např. HTTP klient)
- (-) Omezení zpracovávaných dat (body, headers)
Příklady
- Potřebuji zpracovávat chybové odpovědi HTTP, ale v Camelu nevím, jak se k nim dostat. Chybová zpráva je dokonce spolknutá, nevím, jak se ní dostat. A vůbec se proklikat tím kódem, abych tohle zjistil
- Nevím, jak moc je Camel optimalizovaný na rychlost, ale moc bych neřekl. To budu těžko měnit a já se pohybuji v prostředí high-frequency, kde každá vteřina rozhoduje. Sice s Camel 4 prý udělali velké pokroky, ale bude to dost? Hlavně to příliš nezměním, je tam zbytečný overhead celou contextu, běžících route
- Programovat všechno ve formě message routes je strašné. Je to úplně přes ruku, hlavně já to vůbec nepotřebuji. Já nepotřebuji routovat zprávy nikam a integrovat systémy A, B, C. Já potřebuji jen reagovat na události.
Závěr
Bez Camelu
Ta myšlenka Camelu vypadá dobře a myslím, že na integraci systému něco jako ETL to může být i super věc, ale můj use case je celkem jednoduchý, ani se nejedná o nějakou složitou integraci, prakticky jen REST API a Websocket, případně soubory či DB na sběr dat. Ale ty problémy a složitost, které Camel s sebou přináší mi rozhodně nevyváží těmi přínosy, které téměř vlastně ani nejsou...
Dnes (17.3.2025) mi došla ještě jedna věc ohledně Camelu, respektive EIP. EIP je skvělá věc, protože stejně jako Design patterns to jsou opakující se vzorce v integracích - retry, error handling, mergování, splitování, agregování, message bus atd. Nicméně ta implementace v podání Camel není úplně povedená, ať si tvrdí kdo chce co chce. Jako natlačit vše do route? Jen testování a debugování je očistec.