Messaging, czyli po co nam komunikacja asynchroniczna?

[@DevMentorsPL]

Link do repo projektu: github.com/devmentors/Messaging-Pragmatycznie-KZbin

[@marcin73523]

Kiedy powrót Piotra?

[@uskrzydlacz]

2:05:54 Na produkcji to mam nadzieje nikt nie używa tylko jednej instancji RabbitMQ, tylko albo kilku z load balancer-em albo klaster z mirrored queues. Poza tym lepsza i bezpieczniejsza jest Kafka Apache :) Pozdrawiam

[@DevMentorsPL]

Kto klaster RMQ konfigurował na prodzie ten w cyrku się nie śmieje 🥲 Inna sprawa, ze Mirrored (Classic) Queues stają się już deprecated na rzecz od dawna dostępnych Quorum Queues. 😉

[@Adonn-qv4xh]

Po przerobieniu kursu z mikroserwisów, w pierwszej kolejności polecacie przerobić kurs Messaging: Pragmatycznie czy Domain-Driven Design: Pragmatycznie?

[@DevMentorsPL]

Raczej DDD, ponieważ pozwoli to zaprojektować granice mikrousług :)

[@besem1]

Hej, a czy to trochę nie jest tak, że za pierwszym razem po prostu użyliście niepoprawnego rozwiązania do komunikacji pomiędzy dwoma klockami, czyli REST? Odniosłem wrażenie, może mylne, że "narzekacie" na HTTP, gdzie bardziej bym narzekał na RESTa. W RabbitMQ z tego co widzę, to producent jak i konsument również mogą po HTTP wysyłać i odbierać wiadomości. Nie wiem czy dobrze to sobie układam w głowie ;) Ogólnie bardzo fajny materiał, dzięki!

[@marcin73523]

Nie chodzi o protokół tylko mechanizm komunikacji Jak idziesz do lodziarni to pracownik robi wszystko przy tobie, stoisz obok, czekasz, jak skończy to od razu masz wynik. W tym czasie mogłeś robić coś innego a czekałeś, ale czas robienia lodów jest tak krótki że to nie przeszkadza. Jak zamawiasz coś w restauracji to składasz zamówienie i dostajesz potwierdzenie że twoje zamówienie pojawiło sie na liście w kuchni. Nie wiesz kiedy ktoś zacznie je robić ani kiedy skończy, jedynie wiesz że jest na liście, w niektórych miejscach dostajesz informacje na którym miejscu w kolejce jesteś. Drugie rozwiązanie pozwala bardzo zaoszczędzić zasoby, bo nie musisz mieć tłumu kucharzy którzy każdego klienta będą obsługiwać od razu. Jeśli jest mały ruch to obsłużą szybko, jak duży to klient chwile poczeka. Jest jeszcze jeden plus czyli zapis zamówienia, jeśli kucharza pogryzą szczury i trzeba będzie go wyrzucić, to zamówienie dalej jest na liście, kolejny kucharz może się nim zająć jak akurat będzie miał czas. Masz gwarancje że jak jesteś na liście (w kolejce) to kiedyś ktoś sie zajmie twoim zamówieniem, ono nie przepadnie Ten sam mechanizm można zastosować w wielu miejscach, tak samo działa oddawanie samochodu do mechanika, albo zlecanie wrzucenia ogłoszenia na portal ogłoszeniowy, zlecenie przelewu Dostajesz informacje że zamówienie jest przyjęte a czy ktoś je zrobi za 2 sekundy czy za pół dnia, to już zależy od obecnego natężenia ruchu To nie jest tak że jeden sposób jest lepszy od drugiego, trzeba używać obu zależnie od potrzeb, czasami coś musi być wykonane natychmiastowo a czasami może poczekać, jak może poczekać to można użyć kolejki A to czy kawałek tekstu prześlesz po http, rpc, czy smtp, to już sprawa drugorzędna

[@andrzejgadek3374]

"devMentos" ?

[@fuukowatty9817]

Jaka jest zasada starbucksa?

[@DevMentorsPL]

Chodzi przede wszystkim o optymalizacje procesu odbioru i przetwarzania zamowienia od klienta, nie skupiajac sie az tak na skrajnych przypadkach takich jak "co jesli zaczniemy robic kawe, a ktos przy jej odbiorze nie zaplaci (z roznych powodow?". Wiecej tutaj: www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html

[@DevMentorsPL]

Oraz ciekawie rozwinieta mysl na blogu Particular Software: particular.net/blog/what-starbucks-can-teach-us-about-software-scalability

[@DevMentorsPL]

Hej, nie wiem o co chodzi ale odpowiedz od nas "wisi" od 8 dni, wiec wrzucam jeszcze raz: ========================================================================= Chodzi przede wszystkim o optymalizacje procesu odbioru i przetwarzania zamowienia od klienta, nie skupiajac sie az tak na skrajnych przypadkach takich jak "co jesli zaczniemy robic kawe, a ktos przy jej odbiorze nie zaplaci (z roznych powodow?". Wiecej tutaj: www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html Oraz ciekawie rozwinieta mysl na blogu Particular Software: particular.net/blog/what-starbucks-can-teach-us-about-software-scalability

[@grzybson6502]

Ej, co tam robi Berta na Atari 2600? W sumie wiem, że ktoś to pisał w ramach konkursu, bo relacjonował także postępy na atarowskim forum :)

[@DevMentorsPL]

Prezent od autora😉 Trzymamy jako pamiątka po 100 commitach😀

[@belkocik]

Kiedy i gdzie zapowiedziany Rust na kanale?

[@mq9032]

Cześć, jak zrobić takiego landing page, bardzo chciałbym się czegoś takiego nauczyć. Pomoże ktoś?

[@DevMentorsPL]

Hej, strona to w 90-95% HTML i CSS na naprawdę podstawowym poziomie. Pozostałe 5% to pierdoly w JS żeby coś animowac lub rozszerzyć na kliknięciu. Myślę że lizniecie powyższych na poziomie jak używać podstaw HTML i CSS + zrozumienie RWD (mobilki+PC) i jesteś w stanie coś takiego ogarnąć. No i oczywiście wizja jak to ma wyglądać - możesz poćwiczyć inspirując się pracami web designerów na platformach takich jak Behance. Powodzenia! /Michau

[@mq9032]

@@DevMentorsPL Dzięki za odpowiedź