Wg mnie warto nauczyć się jak działa masstransit choćby po to żeby zobaczyć czego będzie brakować jak już trzeba będzie zrobić własny ulep (i wtedy zobaczymy że jest tego w c… i nie warto). Moje podejście to zawsze startować z masstransit i zmienić tylko jeśli faktycznie nie będzie się dało obejść jakiejś abstrakcji.
Tak, mozna iść w RawJson, powylaczac tworzenie topologii (zaleznie czy to producent czy konsument) plus wiedziec czego sie spodziewac w payloadzie. Anyway nie zmienia to myślę naszego podsumowania - narzedzie swietne i regularnie rozwijane i utrzymywane. Warto uzywac byle swiadomie. Nie zmienia to faktu, ze mechanical sympathy i tak jest co najmniej wskazane. 😉
@@DevMentorsPL Jakby tu napisać, żeby nie był cały elaborat :D. 1. Kontrakty - jak zmienisz to niezależnie czy MT czy raw mocno ryzykujesz. Jedynie przyrostowe zmiany są bezpieczne. Cała reszta zmian - i tak musisz wiedzieć co robisz - MT czy nie. 2. Wiele zespołów - różne technologie. a) Kto narzuca kontrakt? W MT to konsumer - bo on tworzy topologię. Więc argument, że konsumerowi nie spodoba się własny kontrakt jest trochę trudny do przełnięcia. Chyba, że mówimy o tym, że MT tworzy topologie (bo gdzieś jest konsumer, który ma ustowionego prefetch na 0??), ale chyba to już wysoki poziom kopania samego siebie tam gdzie boli.... b) Producent - tu wchodzi RawJson i znowu pytanie - kto dyktuje kontrakt? Zwykle to nie producent tylko konsumer więc jakiekolwiek zmiany i tak muszą być syncowane z teamem od consumera. W MT można publikować bezpośrednio na exchange albo queue. W środowiskach wielozespołowych i wielu technologii branie MT czy raw na pałę zawsze będzie bolało. Są scenariusze, gdzie w MT będą bolały trochę mniej. Ale prawdą jest, że w MT jest troche gotcha. Jak i w rabbicie (inaczej byście nie robili kursu ;)). No i nie słyszałem nic o całym resiliency (albo niewiele), które MT daje out-of-the box - retry, redelivery (no tak, z Hangfire lub Quartz), circuit breaker, kill switch, inbox/outbox pattern, reconnect do klastra on failure. Dawno z rabbit driverem nie pracowałem, ale jak ostatnio miałem tą przyjemnosć to nie umiał zmienić sobie noda i trzeba było samemu pisać handling na to. MT daje takie resiliency out of the box. Z drugiej strony to pewnie zamierzchłe czasy pracowania z kolejkami typu classic...więc może bullshit - don't know. Może zrobicie taki scenariusz w kursie? Nie chcę brzmieć jak fanboy MT, ale mam wrażenie, że nie wszystkie zarzuty i scenariusze były fair... Poza tym zajebistą robotę robicie, dzięki! Kursik wpadł, czekam na marzec.
Super materiał - pozdrawiam Panowie BTW wyciągnijcie Piotrka z szafy :)
Fajne, przystępne i dowiedziałem się czegoś nowego. Dzięki Panowie!
Jeśli chodzi o scheduling to MassTransit wspiera też natywne mechanizmy Rabbita/Azure Service Busa itd
Wg mnie warto nauczyć się jak działa masstransit choćby po to żeby zobaczyć czego będzie brakować jak już trzeba będzie zrobić własny ulep (i wtedy zobaczymy że jest tego w c… i nie warto). Moje podejście to zawsze startować z masstransit i zmienić tylko jeśli faktycznie nie będzie się dało obejść jakiejś abstrakcji.
MassTransit można skonfigurować tak, żeby nie opakowywał wiadomości w kopertę.
Tak, mozna iść w RawJson, powylaczac tworzenie topologii (zaleznie czy to producent czy konsument) plus wiedziec czego sie spodziewac w payloadzie.
Anyway nie zmienia to myślę naszego podsumowania - narzedzie swietne i regularnie rozwijane i utrzymywane. Warto uzywac byle swiadomie.
Nie zmienia to faktu, ze mechanical sympathy i tak jest co najmniej wskazane. 😉
@@DevMentorsPL Jakby tu napisać, żeby nie był cały elaborat :D. 1. Kontrakty - jak zmienisz to niezależnie czy MT czy raw mocno ryzykujesz. Jedynie przyrostowe zmiany są bezpieczne. Cała reszta zmian - i tak musisz wiedzieć co robisz - MT czy nie.
2. Wiele zespołów - różne technologie.
a) Kto narzuca kontrakt? W MT to konsumer - bo on tworzy topologię. Więc argument, że konsumerowi nie spodoba się własny kontrakt jest trochę trudny do przełnięcia. Chyba, że mówimy o tym, że MT tworzy topologie (bo gdzieś jest konsumer, który ma ustowionego prefetch na 0??), ale chyba to już wysoki poziom kopania samego siebie tam gdzie boli....
b) Producent - tu wchodzi RawJson i znowu pytanie - kto dyktuje kontrakt? Zwykle to nie producent tylko konsumer więc jakiekolwiek zmiany i tak muszą być syncowane z teamem od consumera. W MT można publikować bezpośrednio na exchange albo queue. W środowiskach wielozespołowych i wielu technologii branie MT czy raw na pałę zawsze będzie bolało. Są scenariusze, gdzie w MT będą bolały trochę mniej. Ale prawdą jest, że w MT jest troche gotcha. Jak i w rabbicie (inaczej byście nie robili kursu ;)).
No i nie słyszałem nic o całym resiliency (albo niewiele), które MT daje out-of-the box - retry, redelivery (no tak, z Hangfire lub Quartz), circuit breaker, kill switch, inbox/outbox pattern, reconnect do klastra on failure. Dawno z rabbit driverem nie pracowałem, ale jak ostatnio miałem tą przyjemnosć to nie umiał zmienić sobie noda i trzeba było samemu pisać handling na to. MT daje takie resiliency out of the box. Z drugiej strony to pewnie zamierzchłe czasy pracowania z kolejkami typu classic...więc może bullshit - don't know. Może zrobicie taki scenariusz w kursie?
Nie chcę brzmieć jak fanboy MT, ale mam wrażenie, że nie wszystkie zarzuty i scenariusze były fair... Poza tym zajebistą robotę robicie, dzięki! Kursik wpadł, czekam na marzec.