Żegnamy lato, witamy jesień! A z nią: DevTalk wraca na antenę po wakacyjnej przerwie! Z utęsknieniem na ten moment czekałem, przyznać muszę. I bardzo fajnie mi się dzisiejszy odcinek nagrywało.
Waszym i moim gościem jest Robert Pankowecki: programista Ruby… i nie tylko. Występuje na konferencjach, pisze książki (sic!), bloguje itede. Zresztą, sam się porządnie przedstawi po naciśnięciu PLAY. Na Twitterze: @pankowecki. Na Snapchacie: pankowecki.
Mamy dziś tech-mięsko: na tapetę bierzemy SAGI. Co to jest i po co to jest, w jakich scenariuszach je implementować i jak je przetestować? Poruszamy bardzo wiele tematów związanych z tym zagadnieniem, ślizgając się również po powiązanych kwestiach. Niejednokrotnie kwestie te doczekały się własnych dedykowanych odcinków podcasta, linki do nich znajdziecie niżej.
Daj znać w komentarzu jak się podobało. Podziel się w socialach. Rośnijmy w siłę.
Dodatkowo gorąco proszę o wejście na iTunes (http://devtalk.pl/itunes) i zostawienie tam oceny/recenzji. Pomoże to w walce o lepszą pozycję DevTalk na ajtunsowej liście. A zajmowaliśmy tam już miejsce w pierwszej trójce podcastów technologicznych najchętniej słuchanych przez Polaków!
Oprócz tego podczas minionych wakacji liczba odsłuchań podcasta przekroczyła 100 tys! I to tak całkiem znacząco.
Najs i spox z podzięxem!
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki
- tech-teksty Roberta: https://blog.arkency.com/by/pankowecki/
- prezentacja Roberta na temat sag: https://blog.arkency.com/course/saga/
- inne powiązane odcinki DevTalk:
- original saga patterns
- saga – process manager
- other
- http://verraes.net/2014/05/functional-foundation-for-cqrs-event-sourcing/
- http://stackoverflow.com/questions/15528015/what-is-the-difference-between-a-saga-a-process-manager-and-a-document-based-ap
- http://blog.devarchive.net/2015/11/saga-vs-process-manager.html
- https://groups.google.com/forum/#!topic/dddcqrs/tRUKojSSUfw
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
Super odcinek! Da się odczuć, że model aktorowy jest przydatny.
“Saga (…) skedżuluje taki komand (…) – zkapczuruj tę transakcję”
LOL :)
Orkiestruj defaultowe settingsy … i wszystko będzie jasne.
Z jednej strony to dziwnie brzmi ale z drugiej jak np przetłumaczyć “cherry-pickować commita na heada brancha” ;)
Czereśniować zobowiązanie na głowę gałęzi?
Nie przesadzajmy, to normalna sprawa, szczególnie jeśli na co dzień pracuje się z anglojęzycznymi klientami. DevTalk ma być luźną rozmową, a nie kurde wykładem przed profesorskim gronem, gdzie trzeba nad każdym słowem się zastanawiać.
Może pytanie z innej beczki, ale jak autor, doświadczony programista w RoR zapatruje się na Elixir ? Czy środowisko Elixir/Erlang OTP ma szanse przebić się w RoR, zwłaszcza, iż Actor model w Erlangu występuje jako out-of-box.
Zdecydowanie inna beczka ;)
Saga / process manager to koncept (wzorzec). Może być zaimplementowany w dowolnym języku. IMHO nie ma aż tak dużego znaczenia w czym będzie zaimplementowany. Wiadomo (o czym Robert też mówił) że gdzieś będzie łatwiej (bo np. do implementacji możesz wykorzystać wbudowany w platformę actor model (np. Erlang)), gdzieniegdzie trudniej bo musisz sam pewne rzeczy ogarnąć.
Co ma Elixir do RoR? Hmm, … nie wiem :) Inny rodzaj młotka ;) Zależy jakie “gwoździe” masz do wbicia – aby wbić gwoździk w ścianę pod obrazek nie ma sensu używać młotka do wbijania mostowych pali ;)
Hej Pawle,
Nie bawiłem się jeszcze z Elixir/Erlang więc trudno mi się wypowiedzieć na jego temat.
Myślę, że do części community się przebije, na to wygląda. Przy czym mówiąc to mamy na myśli oczywiście taki skrót myślowy, który oznacza, że tak naprawdę RoR community przyjdzie do E/E community po wiedzę i młotki :)
Sam natomiast nie będę raczej obstawiał tego konia. Mam w planach pójść bardziej w JRuby / JVM i jego języki (Clojure/Scala/Java8) oraz biblioteki (Akka) bo widzę tam większy wybór oraz dobry tooling. Czas pokaże czy to dobra droga.
Od siebie mogę polecić tylko używanie narzędzi, które lubisz. Kiedy zaczynałem w Rails firmy robiące w tym w PL można pewnie było policzyć na palacach jednej ręki. Ale podobało mi się więc w to inwestowałe. Nie przejmuje się czy język lub platforma, której używam to ta gdzie pojdzie dużo osób do niej czy mało.
Dziękuję za pytanie.
Hej Robert,
Dzięki za odpowiedź na moje pytanie odnoście przyszłości Ruby oraz Elixir. Wracając do tematu samego podcast-u, to świetnie, iż przekazałeś kiedy powinno stosować się wzorce typu Sagas oraz tendencję do pisanie aplikacji w stylu Event-Driven Development i jakie ma to korzyści na tworzeniem wszelkich rozwiązań opartych o scheduler i cron. Sam jestem zwolennikiem tworzenia aplikacji w duchu pull i reactive niż push, zwłaszcza w czasie, kiedy modne jest pojęcie real-time. Co do Elixir-a, sam też nie jestem przekonany jak przyjmie się w rozwiązaniach komercyjnych Tutaj raczej też skłaniam się do Java/Scala, chociaż same języki w porównaniu z C#, Swift-em czy Elixirem są już nieco w tyle (takie osobiste spostrzeżenie).
Ja mam następujące pytanie. Powiedziane zostało, że saga to przeniesienie transakcji z warstwy bazy danych na warstwę aplikacji. To jest jasne. Jednak rodzi się inne pytanie. W pewnym momencie pan Robert przytoczył przykład z systemem sprzedaży biletów i powiedział, że w pewnych sytuacjach trzeba “odblokować” pieniądze na koncie usera. A co jeśli z jakiegoś powodu nie możemy tego zrobić? np api do płatności jest niedostępne z powodu awarii. Jak w takiej sytuacji powinna zachować się saga?
Hej, tutaj Pan Robert ;)
> A co jeśli z jakiegoś powodu nie możemy tego zrobić? np api do płatności jest niedostępne z powodu awarii. Jak w takiej sytuacji powinna zachować się saga?
Wtedy możesz np zapisać event, że się nie udało i zaplanować powtórkę tej akcji na przyszłość (zakładając, że masz infrastrukturę, która na to pozwala) etc.
Inny przykład, który my mamy, to że obsługujemy faktycznie bramki płatności, które nie mają API do zwrotu pieniędzy :-) Serio. Mają tylko do kupowania.
Na szczęści to jakaś mniejszość, bo to są bramki, w których np. się płaci biorąc kredyt (bo bilet na cały sezon piłkarski taki drogi). W takim wypadku mamy to rozwiązane na innym poziomie. Adapter do tej bramki płatności zwraca informację, że zwrot środków się udał ( cała reszta systemu licząca finanse tak zakłada), ale nie robi tego automatycznie, bo nie może. Zamiast tego wysyła email do działu supportu albo finansów, że mają zrobić zwrot środków ręcznie. To może wymagać od nich przelewu z banku, albo zadzwonienia do firmy, która udziela kredytu, że mają go anulować. Myślę, że to jest jakieś 0.1% przypadków ;) Czyli akurat ktoś miał race condition i akurat płacił bramką płatności, która nie wspiera zwrotu środków/anulowania płatności. No i wtedy trzeba ręcznie coś ogarnąć.
Mam nadzieję, że pomogłem sobie wyobrazić jak to może działać.
Dzięki za odpowiedź :)
Faktycznie można robić tak jak piszesz. Ja się za bardzo przywiązałem do transakcji i myślenia, że w razie niepowodzenia natychmiast trzeba wycofać zmiany. Jak widać w sagach wycofywanie wprowadzonych zmian również może być rozłożone w czasie.
> myślenia, że w razie niepowodzenia natychmiast trzeba wycofać zmiany.
to jest spoko do pewnego momentu :) Do momentu aż cały proces jest tak skomplikowany albo ma taki contention na jakimś zasobie, że lockowanie i transakcyjność stają się nieadekwatne do wymagań wyajnościowych.
Albo do momentu, gdzie ten proces staje się już rozproszony (distributed) po różnych systemach i nie ma sensu udawać, że możemy to wrapnąć w transakcję :)
Jak długo można warto jednak robić transakcje, bo rollback bardzo prosty, oczywiście.