Marcin Milewicz - Pragmatyczna architektura frontendowa, czyli jaka?

### Overview Prezentacja Marcina Milewicza, Principal Developera i Frontend Architekta w firmie KMD, poświęcona jest pragmatycznemu podejściu do architektury frontendowej. Prelegent odchodzi od czysto taktycznych szczegółów implementacyjnych, skupiając się na architekturze jako procesie podejmowania decyzji projektowych dopasowanych do celów biznesowych tu i teraz, zamiast ulegania zjawisku Hype-Driven Development.

### Key Topics - **Definicja architektury oprogramowania**: Odwołanie do książki Simona Browna *Software Architecture for Developers*, gdzie architektura oprogramowania stanowi sumę architektury systemowej (komunikacja, interfejsy, backend) oraz architektury aplikacji (wzorce, struktura kodu, komunikacja zespołu). Prelegent podkreśla, że architektura to przede wszystkim zbiór decyzji projektowych powiązanych z realiami biznesowymi. - **Hype-Driven Development vs. Pragmatyzm**: Zestawienie bezkrytycznego wdrażania nowinek technologicznych (Clean Architecture, DDD, Storybook, pełna piramida testów: unit, integration, E2E w Cypress czy Playwright) z pragmatyzmem, który definiowany jest jako dostarczanie największej praktycznej korzyści biznesowej w danym momencie przy skończonym czasie i budżecie. - **Specyfika frontendu**: Frontend to aplikacja uruchamiana w przeglądarce (lub środowiskach wyspecjalizowanych, takich jak bankomaty czy aplikacje webowe pokroju Figma i Photoshop w WebAssembly). Nowoczesny frontend przejmuje coraz więcej logiki biznesowej i wymaga bezpośredniej współpracy z interesariuszami. - **Identyfikacja potrzeb i alternatywy zamiast priorytetów**: W rozmowach z klientem pytanie o pojedyncze priorytety prowadzi do sytuacji, w której „wszystko ma najwyższy priorytet”. Zamiast tego architekt powinien identyfikować potrzeby, przedstawiać alternatywne opcje (np. w postaci ADR – Architecture Decision Records) z jawnym określeniem kosztów oraz ryzyk i pozostawić ostateczną decyzję biznesowi.

### Technical Details & Architectural Drivers Prelegent omawia kluczowe drivery architektoniczne determinujące wybory techniczne: - **Zarządzanie danymi i integracje**: Częstotliwość zmian danych, wolumen danych ładowanych do pamięci RAM przeglądarki (np. 150–200 tys. rekordów w systemie bankowym i ograniczenia bibliotek tabelarycznych), architektura API (obecność API Gateway, integracja z mikroserwisami, komunikacja w sieci lokalnej vs. zewnętrznej) oraz konieczność wsparcia trybu offline (Offline First). - **Analiza backlogu i kontekst biznesowy**: Weryfikacja planów na wyższym szczeblu (np. u CTO). Prelegent przytoczył przypadek wyboru Reacta zamiast Angulara ze względu na dostępność specjalistów na lokalnym rynku oraz wcześniejszy zakup gotowego Design Systemu, a także projekt tworzony na 4 tygodnie bez dalszego utrzymania, gdzie pisanie testów integracyjnych widoków było nieuzasadnione ekonomicznie. - **Kwantyfikacja atrybutów jakościowych**: Mierzenie wskaźników wszędzie tam, gdzie to możliwe – m.in. metryki wydajnościowe (Core Web Vitals), pokrycie testami i testy mutacyjne, analityka i audytowalność przy użyciu narzędzi takich jak Matomo, Google Analytics czy Faro. - **Ograniczenia (Constraints)**: - *Regulacyjne i prawne (Regulatory & Compliance)*: Ograniczenia geolokalizacji danych (np. zakaz przechowywania danych analitycznych poza krajem lub w Google Analytics w określonych instytucjach publicznych w Niemczech i Rosji). - *Technologiczne (In-house Technology)*: Narzucone biblioteki wewnętrzne, wrappery komponentów (np. zmodyfikowany Angular Material ograniczający API), specyficzne mechanizmy renderowania czy niestandardowe biblioteki logujące. - *Skalowanie zespołu (Team Scaling)*: Dostępność programistów na danym rynku pracy (np. trudności w rekrutacji programistów Angulara w Anglii czy dominacja programistów C++ we Wrocławiu ze względu na obecność Nokii). - *Biznesowe*: Budżet oraz Time to Market, gdzie szybsze wdrożenie na produkcję z dopuszczeniem drobnych błędów może przeważać nad rozbudowanymi pipeline'ami CI/CD.

### Takeaways - Architektura nie jest wyryta w kamieniu, lecz jest „zbiorem decyzji wyrytym w czasie” i ewoluuje wraz ze zmianami wymagań. - Decyzje o strukturze (SPA, PWA, SSR, mikrofrontendy, podział na warstwy) powinny wynikać bezpośrednio ze zdefiniowanych wcześniej driverów architektonicznych, a nie od nich zaczynać. - Zadaniem architekta jest przekładanie kwestii technicznych na język kosztów i ryzyk biznesowych, co umożliwia podejmowanie świadomych decyzji.