11 artykułów to nie koniec. Ich ilość ciągle rośnie.
Payload czy Sanity? Samodzielne hostowanie czy SaaS ? Świetny edytor kolaboracyjny czy pełna kontrola nad danymi i przewidywalne koszty przy skali? Wybór CMS-a to poważna decyzja architektoniczna i jego zmiana np. w połowie projektu jest dużo droższa niż zmiana warstwy widoku. Po podjęciu decyzji żyjesz z jej konsekwencjami przez przynajmniej kilka następnych miesięcy.
Architektura oprogramowania to świadome decyzje o tym, jak podzielić system na części, jak nimi zarządzać i jak mają się komunikować. Dobra architektura ułatwia rozwój, testowanie i utrzymanie, a zła potrafi spowolnić każdy kolejny krok.
W tej sekcji zbieram artykuły o projektowaniu aplikacji webowych: struktura projektu, granice modułów, zależności, wzorce oraz kompromisy, które trzeba świadomie podejmować. Piszę praktycznie, pokazując, jak podejmować decyzje, które dobrze starzeją się wraz z rosnącym projektem i zespołem.
Połączenie perspektywy produktu, dewelopera i marketingu w jednym miejscu
Konsultacje
Markdown w plikach projektu działa sprawnie, dopóki treść piszą osoby, które swobodnie pracują w Git. W sytuacji, kiedy klient chce sam zmienić cennik, a redaktor poprawia nagłówek w piątek po południu, repozytorium przestaje być wygodnym CMS-em. Wtedy najlepszy będzie headless CMS, czyli panel dla redakcji i API dla Astro.
Maciej Sala
Founder StriveLab
Klasyczny formularz bardzo szybko robi się ciężki przez takie elementy jak endpoint, odczytywanie ciała żądania, walidacja, statusy HTTP, fetch po stronie klienta i typy przepisane drugi raz. Na ratunek przybywają Astro Actions: wystarczy, że zdefiniujesz logikę funkcji serwerowej, dodasz schemat Zod i wywołasz ją z klienta bez ręcznego składania REST API.
Maciej Sala
Founder StriveLab
Każda aplikacja prędzej czy później wymaga zabezpieczenia wybranych ścieżek, takich jak panele użytkownika, profile czy panele administracyjne. Pytanie, gdzie powinna znajdować się bramka? W przypadku Astro najwygodniejszym rozwiązaniem jest middleware, pozwalający na centralne obsłużenie autoryzacji przed wyrenderowaniem strony. W dalszej części pokażę, jak zidentyfikować użytkownika, przekazać jego dane dalej przez context.locals oraz dlaczego w nowych projektach warto wybierać Better Auth zamiast Lucia.
Maciej Sala
Founder StriveLab
Są łatwiejsze, ale i trudniejsze migracje frontendu. Najtrudniejsza to taka, w której nie możemy przepisać wszystkiego od zera , ponieważ aplikacja działa na produkcji, generuje przychód i nie wolno jej zatrzymać. Jednorazowe przepisanie całego systemu w takiej sytuacji jest bardzo ryzykowne. W artykule piszę, jak architektura wysp w Astro pozwala Reactowi, Svelte i Vue współistnieć w jednym projekcie i jak wykorzystać to do stopniowej, bezpieczniejszej migracji.
Maciej Sala
Founder StriveLab
Zero JavaScript by default to chwytliwy slogan. Architektura, którą on opisuje, to coś większego: cały projekt może być statycznym HTML, a interaktywność — precyzyjnie rozmieszczonymi wyspami. Każda wyspa to niezależna jednostka z własnym frameworkiem, własnym cyklem hydratacji i własnym kosztem runtime. React, Vue, Svelte, Solid — na jednej stronie, pod jedną konfiguracją Astro. To nie eksperyment — to strategia migracji i narzędzie dla organizacji, które nie mogą sobie pozwolić na przepisanie wszystkiego od zera.
Maciej Sala
Founder StriveLab
Brak walidacji frontmattera to prosta droga do błędów: literówki, brakujące opisy czy niespójne tagi stają się uciążliwym problemem, który odkryjemy dopiero na produkcji. Content Collections eliminują to ryzyko, wymuszając zgodność każdego pliku ze zdefiniowanym schematem, co zatrzymuje build, zanim błędne dane trafią na serwer.
Maciej Sala
Founder StriveLab
Zero JavaScript domyślnie brzmi jak jakaś reklama, ale dane jasno pokazują, że to architektoniczna decyzja, która daje do myślenia: Lighthouse powyżej 95, TBT bliski zera, Google dostaje czysty HTML od razu. Klasyczne aplikacje SPA wysyłają do przeglądarki cały framework, nawet jeśli większość strony to statyczna treść. W tym artykule rozkładam mechanizm wysp na części i pokazuję, kiedy daje realne korzyści, a kiedy nie.
Maciej Sala
Founder StriveLab
Masz działający projekt na Pages Router i chcesz wejść w Server Components, streaming albo Server Actions. Tylko że przepisanie wszystkiego naraz to proszenie się o regresję, więc tego lepiej nie robić. Rozwiązaniem jest Pages i App Router obok siebie w jednym repozytorium i przenoszenie strona po stronie, potem testy i bezpieczne deploye.
Maciej Sala
Founder StriveLab
W Next.js traktuj Server Actions i Route Handlers jako cienkie adaptery wejścia: pobierają sesję, walidują payload i mapują odpowiedź. Reguły biznesowe trzymaj w Service Layer, zapytania do bazy w Repository, a transakcje spinaj przez Unit of Work. Taki podział nie jest potrzebny w każdym CRUD-zie, ale zaczyna się zwracać, gdy jedna operacja dotyka kilku tabel, kilku wejść albo kilku reguł.
Maciej Sala
Founder StriveLab