Better Software Design

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

Zostać CTO i móc samodzielnie podejmować wszystkie decyzje techniczne w projekcie i mieć ostateczne zdanie na każdy temat... Taka wizja przyszłości w nawet średniej wielkości organizacji często nie ma jednak zbyt wiele wspólnego z rzeczywistością. Na czym więc polega rola Chief Technology Officera i ile jest w niej realnie technologii?

W wiadomościach od was, na równi z tematami o architekturę, EventStorming czy Domain-Driven Design przewijają się bardo często pytania o dalszą karierę. W jakim kierunku się rozwijać, czy wiązać dalsze plany w IT ze ścieżką stricte techniczną i zostać np. architektem, czy może całkowicie skręcić w stronę managementu i kierowania zespołem czy projektem... W tym wszystkim pytania związane z funkcją i rolą CTO padały chyba najczęściej. Tak więc temat w końcu zagościł na antenie.

Dziś zapraszam Cię na rozmowę z Danielem Owsiańskim, na tematy związane właśnie z funkcją Chief Technology Officera i zarządzania technologią w firmie. Wybór gościa był jak zwykle nieprzypadkowy — Daniel pełni rolę CTO w Volt.io, gdzie mamy okazję na codzień współpracować.

Jeśli chciałbyś/-abyś dołączyć do jednego z naszych projektów w Java, Go lub PHP, tutaj znajdziesz aktualne oferty pracy.

Zapraszam Cię także do odwiedzenia bloga Daniela, owsianski.com, który ostatnio pojawił się w sieci.

Wiele osób chciałoby przy każdym projekcie pracować w green-fieldzie i móc wszystkie decyzje podejmować samodzielnie. Rzeczywistość jest jednak zwykle całkowicie inna, musimy żyć z odziedziczonym kodem i zaprojektowanym modelem. Taki green-field, w którym można zacząć projektować i wdrażać nowy model i techniki DDD, można jednak sobie wykroić.

Wspólnie z Marcinem Markowskim rozmawiamy dziś o technikach Bubble Context, Autonomous Context i Legacy As Exposed Service Erica Evansa, dzięki którym można zacząć refaktoryzację legacy. Z mniejszym lub większym związaniem z legacy, w zależności od potrzeb i możliwości w projekcie.

W dzisiejszej rozmowie:

• na czym polegają techniki Bubble i Autonomous Context,
• kiedy warto, a kiedy nie, korzystać z ich możliwości,
• wykorzystaniu istniejących danych w nowym modelu domenowych,
• ACL-backed repository, Ports & Adapters i innych przydatkach tu technikach,
• jakie synchronizować dane między kontekstami i jakie inne wyzwania staną prawdopodobnie na drodze ku lepszemu,
• współpracy w zespole przy wdrażaniu takich technik.

Materiały dodatkowe:

• Artykuł Getting Started with DDD when surrounded by legacy systems Erica Evans, 2013