Ponad 2000 osób w 500 zespołach, 3000 różnych mikroserwisów i kilkaset tysięcy eventów na sekundę - skala Allegro zawsze robi wrażenie. Jak w tym wszystkim wdrożono architekturę mikrofrontendów, która pozwala sprawnie łączyć różne mikroserwisy i tworzyć podstrony największego w Polsce e-commerce'u prosto z panelu?

W drugiej części rozmowy o mikrforontendach, Bartosz Gałek, Principal Engineer w Allegro, uchyli rąbka tajemnicy i przedstawi trochę technikaliów.

W tym odcinku usłyszysz między innymi o:

• skali systemu, z jaką mierzą się zespoły developerskie Allegro
• wybranych metrykach zapewniających observability systemu od strony frontendowej
• projektowaniu optymalizacji i zapewnianiu dużej wydajności systemu
• projektowaniu stron portalu z użyciem komponentów i wprowadzaniu nowych funkcjonalności na produkcję
• streamingu HTML-a
• stopniowej migracji monolitu do architektury mikroserwisowej

Dzięki Bartkowi mamy możliwość zajrzeć za kulisy i zobaczyć co się dzieje "pod maską" Allegro, gdy odwiedzasz przykładowo podstronę interesującego Cię produktu. I dlaczego, dzięki stosowanym rozwiązaniom i optymalizacjom, jest to tak wydajne...

Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.

YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.

Rozpraszanie systemu na szereg działających niezależnie od siebie usług, przy wszystkich oczywistych korzyściach dla ogólnej architektury i współpracy pomiędzy zespołami, niesie za sobą kilka istotnych konsekwencji. Przykładowo, dostarczenie zdarzenia czy innego komunikatu pomiędzy serwisami przestaje być już tak oczywiste i bezproblemowe, jak to jest w przypadku monolitycznych aplikacji komunikujących się wewnątrz in-memory.

Sieć ze swojej natury bywa zawodna, przerwa w dostarczaniu wiadomości, czy też dostarczanie ich do konsumentów w losowej kolejności nie są sytuacjami czysto hipotetycznymi. Wcześniej czy później taka sytuacja przydarzy się w systemie, pytanie brzmi tylko "kiedy"...

Michał Ostruszka w dzisiejszej rozmowie zarysowuje kilka wzorców w kwestii gwarancji dostarczania wiadomości, które obok Outbox Pattern warto mieć w swojej architektonicznej skrzynce z narzędziami.

Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.

YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.

Termin "microservices architecture" w ostatnich latach był odmieniany przez wszystkie możliwe przypadki. Przeważnie jednak ten styl architektoniczny przewijał się w kontekście rozwiązań backendowych i wyciągania z monolitów fragmentów jego funkcjonalności. Rzadko jednak mówiło się o projektowaniu rozwiązań frontendowych w tego rodzaju systemach...

Netlifx, Amazon, Spotify czy Uber - te firmy przychodzą z pewnością na myśl jako przykłady popularnych wdrożeń mikroserwisów. W Polsce zdecydowanie jest to Allegro, które dokonało migracji z monolitycznego systemu PHP do właśnie takiej architektury i innych technologii.

Tomasz Ducin i Bartosz Gałek, Principal Engineer w Allegro, zaglądają "pod maskę" największego portalu ecommerce w Polsce, aby porozmawiać na temat architektury microfrontendów.

Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.

Tworzenie integracyjnych środowisk testowych w całym przedsiębiorstwie jest powszechną, marnotrawną praktyką, która spowalnia wszystko i wszystkich. Brzmi ostro lub może także nawet znajomo? Ale właśnie w taki sposób duże środowiska integracyjne są określane w kolejnych wydaniach Technology Radaru Thoughtworks i to od 2017 roku! O rok dłużej, bo od 2016 raport ten sugeruje także wdrażanie testów kontraktowych jako jedno z możliwych rozwiązań tego problemu.

Temat samych testów kontraktowych pojawił się już w podkaście, w odcinku "O testowaniu kontraktowym z Rafałem Maciakiem". W dzisiejszej rozmowie, wraz z Jackiem Milewskim, uzupełniamy to podejście o aspekty praktyczne, aby zabezpieczanie komunikacji pomiędzy serwisami nie stało się szybko długiem technicznym, którego utrzymanie będzie kosztować wszystkie zespoły czas i niepotrzebne nerwy.

Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.

W pierwszym odcinku w 2025 roku zapraszam na pierwszą odsłonę Backend vs Frontend, gdzie wspólnie z Tomkiem Ducinem bedziemy pochylać się nad różnymi problemami związanymi z software developmentem. Na początek temat testowania i testów integracyjnych, bo jeśli nie testujesz swojego kodu, to jak możesz mieć pewność, że wszystko działa poprawnie?

Ale “hold your horses”… testy to tylko przyczynek do tego, aby porozmawiać w luźnej atmosferze o wielu ważnych rzeczach dookoła.

Dziś już chyba nie ma sposobu, by uciec od tematu sztucznej inteligencji i jej wykorzystania w codziennej pracy. I właśnie często pojawiające się pytanie o wpływ sztucznej inteligencji na wytwarzanie oprogramowania i zawód programisty jest przyczyną dzisiejszego odcinka. A że taką małą tradycją w tym podkaście powoli staje się doroczne spotkanie z Jarkiem Pałką i Wojtkiem Ptakiem, temat rozmowy narzucił nam się niemal od razu. I choć wiele z tego zdezaktualizuje się zapewne bardzo szybko, to tak właśnie widzimy zastosowanie AI w IT, anno domini 2024.

W świecie technologii frontendowych, w najprostszym rozumieniu moduł może być najmniejszą cząstką aplikacji, zajmującą się jedną podstawową rzeczą, dodatkowo wydzieloną do osobnego miejsca. Ale aby nie było zbyt prosto, to tylko jedna z często stosowanych definicji modułu.

W dzisiejszym odcinku gościem Tomka Ducina, specjalisty z zakresu architektury frontendu jest Tomasz Jakut, szerzej znany w społeczności JavaScriptowej jako Comandeer.

Więcej na stronie tego odcinka na stronie bettersoftwaredesign.pl.

Architektura systemu nie jest jedynie pochodną wymagań funkcjonalnych. Istotny wpływ ma tu także fakt, czy z system powstaje do obsługi jednej organizacji, czy też będzie z niego korzystać wiele całkowicie osobnych firm, a także w jakim stopniu poszczególni użytkownicy będą wykorzystywać dostępne zasoby. Ale to nie jedyne wyzwania, jakie pojawiają się w architekturach multi-tenant...

Tematy zahaczające o infrastrukturę nie pojawiają się w Better Software Design zbyt często, jednak w przypadku tego rodzaju architektur nie sposób od tego tematu uciec. A moim gościem w tej rozmowie jest dziś Michał Giergielewicz, który na co dzień pracuje przy systemie email-marketingowym, z którego korzysta kilkaset tysięcy klientów na całym świecie.

W tym odcinku wspólnie z Michałem rozmawiamy między innymi o:

• trudnościach w tworzeniu systemów multi-tenant, w tym bazach danych czy kolejkach
• możliwych sposobach zaprojektowania infrastruktury przechowującej dane
• problemach związanych z bezpieczeństwem danych i SQL Jailingu
• aspektach, które warto wziąć pod uwagę projektując system pod równoczesną obsługę wielu klientów
• pytaniach, które mogą pomóc w doborze odpowiedniej architektury
• rozwiązywaniu problemów technicznych za pomocą narzędzi biznesowych

Więcej na stronie tego odcinka na stronie bettersoftwaredesign.pl.

W 2015 roku Meta, a właściwie ówczesny Facebook wydaje pierwszą wersję specyfikacji GraphQL, języka opisu zapytań do API, którego celem jest wydajne i mocno elastyczne pobieranie danych. A ten właśnie problem mocno doskwierał Facebookowi przy implementacji natywnych aplikacji mobilnych. Nadszedł rok 2024 i wiele organizacji przekonało się, że wdrożenie rozbudowanego i wydajnego GraphQL API nie jest zadaniem prostym...

O GraphQL powiedziano już wiele, warto przybliżyć trochę ciemniejszych stron używania tego rozwiązania w projekcie. Dziś zapraszam na rozmowę o cieniach GraphQL-a, a moim gościem jest Sebastian Rabiej, który z tą technologią ma sporo doświadczenia produkcyjnego.

W tym odcinku wspólnie z Sebastianem rozmawiamy między innymi o:

• raporcie Postmana i trendach w stosowaniu poszczególnych styli budowy API
• czym jest GraphQL i jakie problemy rozwiązuje
• zasadach, popularnych narzędziach i frameworkach do budowy GraphQL API
• sposobach atakowania serwera GraphQL
• potencjalnych problemach z wydajnością, bezpieczeństwem i wersjonowaniem takich API
• best practices i sposobach rozwiązania typowych problemów w GraphQL

Materiały dodatkowe:

• Dokumentacja i strona domowa GraphQL
• Dostępne wydania specyfikacji GraphQL
• Artykuł na blogu Meta opisujący jak to się wszystko zaczęło
• Zestaw zaleceń Principled GraphQL
• Praca Migrating to GraphQL: A Practical Assessment
• Wspomniany w odcinku blog post The rise and fall of GraphQL at sennder
• Artykuł Public versus Published Interfaces Martina Fowlera
• [Dokumentacja limitów GraphQL[(https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api) w API GitHub
• Netflix DGS Framework do implementacji i uruchamiania usług opartych o GraphQL
• GraphQL Voyager, narzędzie wizualizacji schematu API w formie interkatywnego grafu
• GraphQL Cop, narzędzie audytu security API opartych o GraphQL

Frontend i jego technologie rozwijają się szybko. Tym razem na horyzoncie w świecie Angulara są Signals, które mogą dość mocno zmienić podejście do projektowania systemu.

Po mocnym otwarciu serii o architekturze frontendu rozmową z Bartkiem Cytrowskim o makro-frontendzie Atlassiana, pora na temat typowo techniczny, związany jak to często w tym światku bywa, z konkretnym frameworkiem. Gościem Tomka Ducina dziś jest Maciej Wójckik, Software Engineer i Technical Leader w Cisco, a tematem rozmowy są wspomiane już sygnały.

W dzisiejszej rozmowie:

• czym są sygnały i jaki problem rozwiązują
• w czym są podobne, a czym różnią się od istniejących narzędzi reaktywnych typu RxJs
• komponentach, zależnościach, zmianach, template'ach i wydajności systemu
• jak sygnały wpływają na projektowanie i testowanie aplikacji
• z czym wiąże się migracja aplikacji na Signals i jakie problemy mogą się pojawić

Materiały dodatkowe:

• Oficjalna dokumentacja Angular Signals
• Darmowy kurs Angular Signals autorstwa Macieja