Java, Spring Boot i enterprise integracje.

Kiedy Java wchodzi do projektu automatyzacyjnego

Cztery sytuacje, w których dokładam Javę do typowego stackowi z n8n:

• Klient ma duży backend w Spring Boot: automatyzacja to rozszerzenie istniejącego systemu, a nie nowa platforma obok. Integrujemy przez REST API tego backendu albo dokładamy nowy moduł w tym samym projekcie.
• Legacy systemy dostępne tylko przez JMS, SOAP albo JDBC: polski ERP, system bankowy z lat 2000, ubezpieczeniowy backend. Napisanie wrappera w Javie z natywnym klientem JMS daje większą niezawodność niż custom Python.
• Wymagania performance dla konkretnego pipeline'u: pipeline obrabiający miliony wiadomości dziennie, gdzie Java na JVM daje przewidywalne opóźnienia i GC, a Python gubiłby się na garbage collection.
• Zespół developerski klienta to Java devs: jeśli long-term maintainerem wdrożenia jest zespół Java, dokładanie Pythona tylko do kilku narzędzi powoduje friction. Lepiej trzymać stack spójny.

W żadnym z tych scenariuszy Java nie zastępuje n8n, tylko go uzupełnia. n8n zostaje warstwą orchestration, Java przejmuje konkretne elementy wymagające głębszej integracji.

Wzorce integracji Java z n8n

Trzy najczęstsze architektury, które projektuję:

Spring Boot jako mikroserwis wołany przez n8n HTTP

n8n wysyła HTTP POST na endpoint Spring Boot (np. /api/erp-push). Serwis obrabia request (validacja, mapping, integracja z ERP), zwraca status. Deployment: JAR plus Docker plus systemd albo Kubernetes. Zalety: proste, łatwe do debugowania, backend może być rozwijany niezależnie od n8n.

Spring Boot jako kolejka JMS między n8n a legacy

n8n publikuje wiadomość do kolejki JMS (Tibco, Solace, ActiveMQ), Spring Boot consumer czyta, przetwarza, potencjalnie publikuje response na innej kolejce. Zalety: asynchroniczna obróbka, buforowanie przy peak'ach, naturalna integracja z legacy enterprise systems, które JMS znają.

n8n zastępuje tylko frontend orchestration, Java utrzymana jako heart

Klient ma istniejący Spring Boot backend z business logic. n8n dostaje role: schedulera, integratora z zewnętrznymi API (CRM, mail), UI do ręcznego triggerowania procesów. Wszystkie ciężkie zadania, bazy danych, reguły biznesowe zostają w Javie.

Integracje z legacy (SOAP, JDBC, JMS)

Trzy typy legacy, z którymi Java radzi sobie lepiej niż Python:

• SOAP z WSDL: enterprise systemy od lat 2000 (SAP, Oracle Financials, polskie ERP) często wystawiają SOAP. Java generuje klient z WSDL (przez wsimport albo Apache CXF), typowanie statyczne chroni przed błędami w runtime. Python requests-soap jest do tego zmuszany ad-hoc.
• JDBC do starszych baz: Sybase, DB2, Oracle Legacy, MSSQL pre-2012. Java sterowniki JDBC są dobrze utrzymane i pokrywają wszystkie funkcje. Python ORM-y (SQLAlchemy) mają ograniczenia dla starszych baz.
• JMS queues: Tibco EMS, IBM MQ, Solace, Apache ActiveMQ. Natywne klienty Java (JMS 2.0 API) są standardem, Python ma biblioteki stomp/pika, ale dla enterprise JMS brakuje funkcji (distributed transactions, topic hierarchy).

Java stack, który używam

Preferencje, które wracają w moich projektach:

• Java 21 (LTS, Virtual Threads dla wysokiej równoległości). Dla legacy klientów Java 17, minimum Java 11. Starsze wersje nie wspieram.
• Spring Boot 3.x: REST API, dependency injection, auto-configuration. Znany, dobrze udokumentowany.
• Gradle Kotlin DSL: bardziej czytelny niż Groovy dla nowych projektów, XML-y Maven-owe odkładam dla klientów, którzy tego wymagają.
• JUnit 5 plus Testcontainers: testy integracyjne z prawdziwą bazą w kontenerze, zamiast mockowania. Łapie realne problemy ze sterownikami JDBC i queries.
• MapStruct: mapping DTO-Entity bez ręcznego pisania setterów. Annotation processor, zero runtime overhead.
• Resilience4j: circuit breakers, retries, rate limiting dla integracji zewnętrznych. Naturalny wybór w ekosystemie Spring Boot.
• Micrometer plus Prometheus: metryki wystawiane na /actuator/prometheus, grafana-friendly.

Kiedy Java to przesada

Scenariusze, w których odradzam Javę i rekomenduję Python albo czyste n8n:

• Prosty skrypt ETL raz dziennie: jeden plik CSV do bazy, transformacja jakościowa, push do API. Python w 30 linijkach robi to samo, co Spring Boot w 5 plikach plus Maven pom.xml.
• Prototyp, który ma zweryfikować pomysł: time-to-first-run w Pythonie jest krótszy. Kiedy pomysł się potwierdzi, migracja do Javy jest niewielkim kosztem.
• Automatyzacja w małej firmie bez Java devs: long-term utrzymanie Javy wymaga ludzi, którzy ją znają. Bez tego wdrożenie po roku staje się niemożliwe do modyfikacji.
• Integracje z nowoczesnymi SaaS REST API: HubSpot, Pipedrive, Slack, Notion, Airtable. n8n ma natywne node'y, Python ma bibliotek, Java by wymagała ręcznego klienta. Overkill.

Najczęstsze pytania

Co warto przeczytać obok