Apache Kafka jako łącznik między front, a backendem

Szukałem odpowiedzi na moje pytanie ale nie znalazłem. Właściwie to mam dwa:

Czy zakładając, że front mojej aplikacji mam napisany w Vaadinie i nie chcę zbytnio uzależniać od siebie frontu i backu, to dobry pomysłem jest ustawienie pomiędzy nimi Kafki ? Czy zastępowanie nią w tym wypadku zwykłego RESTa to niepotrzebne zawracanie głowy ?

Drugie pytanie, to czy jeżeli obie apki będą stały na jednym Tomcacie (czy tam Netty) to opłaca się wtedy wstawiać Kafkę jeżeli komunikacja odbywa się tylko w obrębie jednej maszyny (czyli po lokalu gdzie opóźnienia są znikome) ?

Rozważania póki co teoretyczne.

1. Wydaje się Apache Kafka posłuży do różnorodnych połączenie "poziomych" *) gdy pytając o Vaadima Ty pytasz o "pionowe".
2. Wszelkie Kafki są do zmiany modelu z synchronicznych na asynchroniczne. Nawet na szybkim stosie 3 warstwy synchronicznego jednak "trochę" kosztują. Nigdy nie mów przy webserwisach, że koszt sieci jest zero.
3. A może jednak monolit ?

*) obrazowo. Jestem starym Wicket'arzem, który ma podobną koncepcję do Vaadima.

AnyKtokolwiek napisał(a):

1. Wydaje się Apache Kafka posłuży do różnorodnych połączenie "poziomych" *) gdy pytając o Vaadima Ty pytasz o "pionowe".

Czyli jednak sam REST ?

2. Wszelkie Kafki są do zmiany modelu z synchronicznych na asynchroniczne. Nawet na szybkim stosie 3 warstwy synchronicznego jednak "trochę" kosztują. Nigdy nie mów przy webserwisach, że koszt sieci jest zero.

Możliwe, właśnie dlatego pytam :) I Kafka by tu jednak coś pomogła ?

3. A może jednak monolit ?

A jak w przyszłości będę chciał zrezygnować z Vaadina na rzecz na przykład Angulara ? Wydaje mi się, że w monolicie byłyby te warstwy dość mocno ze sobą zaplątane i mógłby być problem.

Załóżmy, że Kafkę tam wstawisz. Jaki problem Ci to rozwiązuje?

Nie wiem, usuwa ewentualne opóźnienia, który mogłyby się pojawić przy dużym ruchu ? O Kafce wiem tyle ile przeczytałem na stronie Apache i temat mnie zaciekawił, każda informacja będzie dla mnie cenna. Nie to, że upieram się przy jakimś rozwiązaniu, po prostu fajnie gdyby ktoś napisał na przykład: to nie będzie dobre, ponieważ to i to.

slayer9 napisał(a):

Nie wiem, usuwa ewentualne opóźnienia, który mogłyby się pojawić przy dużym ruchu ? O Kafce wiem tyle ile przeczytałem na stronie Apache i temat mnie zaciekawił, każda informacja będzie dla mnie cenna. Nie to, że upieram się przy jakimś rozwiązaniu, po prostu fajnie gdyby ktoś napisał na przykład: to nie będzie dobre, ponieważ to i to.

Usuwanie opóźnień przy asynchronicznym modelu nie jest jakimś 'deux per machina', cudem, magią, szybki jest tylko powrót ze "zlecenia wysyłki". Kiedyś w przysżłości będzie (miejmy nadzieję) event, że uzyskasz potwierdzenie wykonania i stosowne dane (lub go nie będzie i musisz być na to przygotowany)
Nie ma sposobów aby dysponować danymi wcześniej (tzn nie ma sposobów naruszających powszechnie znane zasady fizyki, prędkość światła, teorię informacji itd). Sorry, święty Mikołaj nie istnieje.

Czyli rozwiązujesz problem wydajnościowy, którego nie masz :-)

Podstawowa trudność to koncepcja jak użyć Kafki w Twoim scenariuszu (zintegrować Kafkę i Vaadina).

1. Klikasz coś w GUI - zapisz/zamów/zapłać etc.

2. Vaadin publikuje wiadomość w topiku kafkowym
   Co robisz z GUI? Blokujesz do czasu nadejścia potwierdzenia przetworzenia wiadomości? Wówczas, gdzie zysk nad RESTem? Nie blokujesz? (Jak radzisz sobie z tym, że user kliknie 10x zapisz..)

3. Jak sobie wyobrażasz komunikację w drugą stronę? tj. aktualizacja GUI po tym jak backend przetworzy wiadomość kafkową :-)

Kafka pasuje tutaj jak pięść do oka trochę ;) Kafka nadaje się do takiej sytuacji, gdzie chcesz asynchronicznie streamować eventy, szczególnie do wielu odbiorców. Przykład z komunikacja GUI-backend nijak się w to nie wpasowuje.
Gdzie sie to nadaje?
Wyobraź sobie że użytkownik klika po tym twoim GUI, a serwisy w twojej aplikacji chciałyby o tym wiedzieć (np. serwis który pokazuje userowi "co jeszcze możesz kupić", chciałby analizować co user ogląda w tej chwili i dopasować ofertę pod to). Jednocześnie nie chcesz tam mieć jakiegoś "blokowania", bo co jak userów jest nagle milion i te serwisy rekomendacyjne się dławią? Czemu user miałby nagle czekać 5 minut na przeładowanie strony? ;) Nie interesuje cię też jakoś strasznie zeby to się odbywało synchronicznie - tylko żeby się wykonało.
Albo chcesz zbierać i przetwarzać sobie logi z aplikacji. Każda akcja usera generuje jakieś wpisy w event logu, może robisz tam jeszcze jakieś magiczne wyliczenia statystyk etc. Ale znów nie obchodzi cię żeby taka akcja została zapisana synchronicznie, od razu kiedy user gdzieś kliknie. I nie chcesz zeby user musiał na to czekać, bo nie ma to sensu.

RESTem też da się osiągnąć asynchroniczne przetwarzanie (wystarczy zrobić końcówki, które nic nie zwracają, a do żądań HTTP użyć nieblokującej biblioteki), ale jest pewna wada - odbiorca nie może kontrolować ilości jednocześnie przetwarzanych żądań, więc może braknąć RAMu.

Atutem Kafki jest bufor dyskowy. Dzięki niemu można regulować natężenie jednocześnie przetwarzanych żądań - zbyt szybkie wrzucanie wiadomości do Kafki poskutkuje tymczasowym zwiększeniem bufora dyskowego zamiast zapychać RAM. Ponadto bufor dyskowy jest trwały, więc można restartować aplikację odbierającą wiadomości bez ryzyka ich utraty. Kafka ma też broadcasting, partycjonowanie, replikację, klastrowanie itp itd co można wykorzystać do skalowania aplikacji.