Jak nadmierna standaryzacja frameworków niszczy skalowalność aplikacji

W ciągu ostatnich dwóch lat obserwuję niepokojący wzorzec wśród firm technologicznych: fetyszyzację frameworków. Zamiast traktować je jako narzędzia do rozwiązywania konkretnych problemów, zespoły zaczynają budować wokół nich całą swoją tożsamość. „Jesteśmy Reactowym shopem”, „Działamy tylko w Vue”, „Nasz stack to Next.js + Prisma + Tailwind” – te deklaracje brzmią dumnie na LinkedIn, ale w praktyce często prowadzą do architektonicznych ślepych zaułków, które blokują skalowanie biznesu.

Problem: kiedy framework przestaje być narzędziem, a staje się celem

Klasyczny przykład z mojej praktyki: startup SaaS, który w 2022 roku rozpoczął rozwój platformy w React z Next.js. Początkowo świetnie – szybki prototyp, bogate ekosystemy, łatwe rekrutacje. Problem pojawił się przy 50 tysiącach użytkowników miesięcznie, gdy aplikacja zaczęła wymagać:

• Real-time funkcjonalności poza możliwościami standardowego Next.js
• Specyficznego cache’owania, które kłóciło się z domyślną architekturą
• Integracji z niszowymi usługami backendowymi

Zespół spędził następne 6 miesięcy na „łataniu” frameworka workaroundami, zamiast przeprojektować architekturę pod realne potrzeby. Koszt: 3 opóźnione funkcje kluczowe dla klientów i 40% wyższe koszty infrastruktury.

3 sygnały ostrzegawcze, że framework stał się problemem

1. Więcej kodu omijającego framework niż wykorzystującego go

Gdy ponad 30% kodu to wrapper-y, adaptery i polyfille, które mają „zmieścić” framework do rzeczywistych potrzeb – to czerwona flaga. Widziałem aplikację e-commerce, gdzie zespół napisał własny system routingu, bo domyślny Next.js nie obsługował ich skomplikowanej logiki koszyka. To jak kupić samochód wyścigowy, a potem przerabiać go na ciężarówkę.

2. Rekrutacja pod framework, nie pod problemy biznesowe

Firmy publikują ogłoszenia: „Poszukujemy Senior React Developera” zamiast „Poszukujemy developera, który zbuduje system rekomendacji dla 100k użytkowników”. Efekt? Zespół świetnie zna konkretną technologię, ale nie ma kompetencji do rozwiązania rzeczywistych wyzwań. W jednej platformie edukacyjnej zespół Reactowy przez 4 miesiące nie potrafił zaimplementować efektywnego systemu cache’owania wideo, bo szukał rozwiązań wyłącznie w ekosystemie React – podczas gdy problem wymagał podejścia full-stack.

3. Koszty utrzymania rosną wykładniczo z każdą nową funkcją

To najważniejszy wskaźnik. Jeśli dodanie nowej funkcjonalności (np. systemu powiadomień real-time) wymaga:

• Przepisania istniejących komponentów
• Dodania kolejnej warstwy abstrakcji
• Zwiększenia zasobów serwerowych o 50%

…to framework prawdopodobnie stał się wąskim gardłem. W przypadku aplikacji finansowej, migracja z Vue 2 na Vue 3 zajęła 8 miesięcy i wstrzymała rozwój nowych produktów – wszystko dlatego, że architektura była tak ściśle związana z konkretną wersją frameworka, że każda zmiana wymagała niemal restartu.

Przypadek z praktyki: kiedy zmiana frameworka uratowała biznes

W 2023 roku pracowaliśmy z firmą z branży PropTech, która miała aplikację do zarządzania nieruchomościami. Ich stack: Angular + Firebase + zestaw specyficznych bibliotek. Przy 10 tysiącach użytkowników aplikacja działała dobrze. Przy 50 tysiącach – zaczęły się problemy z wydajnością, a przy 100 tysiącach koszty infrastruktury przekroczyły budżet.

Analiza pokazała, że:

1. Angular wymuszał pełne przeładowanie aplikacji przy każdej większej zmianie danych
2. Firebase nie skalował się ekonomicznie przy ich modelu danych
3. Specyficzne biblioteki nie miały wsparcia dla nowszych wersji

Zamiast „łatać” istniejące rozwiązanie, zaprojektowaliśmy hybrydową architekturę:

• Frontend: lekkie Preact dla interfejsu użytkownika
• Real-time: własna implementacja WebSockets
• Cache: Redis z customową logiką
• Backend: Go dla części wymagających wydajności

Efekt po 4 miesiącach:

• Koszty infrastruktury spadły o 60%
• Wydajność aplikacji wzrosła 3-krotnie
• Czas ładowania kluczowych widoków: z 4.2s do 0.8s
• Zespół mógł wdrażać nowe funkcje 2x szybciej

Kluczowe było to, że nie chodziło o „najlepszy framework”, ale o odpowiednie narzędzia do konkretnych zadań.

Jak podejść do wyboru technologii w 2024?

Krok 1: Zacznij od problemów biznesowych, nie od technologii

Zadaj pytania:

• Jakie są krytyczne ścieżki użytkownika? (np. zakup w e-commerce, analiza danych w SaaS)
• Jakie są wymagania wydajnościowe? (RPS, czas odpowiedzi, concurreny users)
• Jakie są plany skalowania na 12-24 miesiące?
• Jaki jest budżet i dostępność specjalistów?

Dopiero mając te odpowiedzi, szukaj technologii, które je rozwiązują.

Krok 2: Projektuj pod wymianę komponentów

Najlepsze architektury to takie, w których można wymienić poszczególne części bez rewolucji. Przykład z platformy e-commerce:

• System płatności: niezależny moduł, który można podmienić
• Koszyk: lekka aplikacja, która komunikuje się przez API
• Panel admina: osobna aplikacja z własnym stackiem

Dzięki temu, gdy pojawił się problem z wydajnością koszyka, mogliśmy go przepisać w Svelte bez dotykania reszty systemu.

Krok 3: Mierz rzeczywisty wpływ na biznes

Śledź metryki:

• Koszt utrzymania na użytkownika
• Czas wprowadzenia nowej funkcji
• Satysfakcja zespołu developerskiego
• Wskaźniki wydajności aplikacji

Jeśli któryś z tych wskaźników zaczyna się pogarszać po dodaniu kolejnej funkcji w ramach frameworka – to sygnał do przemyślenia architektury.

Perspektywa na 2024-2025: powrót do pragmatyzmu

Obserwuję trzy trendy:

1. Rozczarowanie monolitami frameworkowymi – firmy, które postawiły wszystko na jeden framework (np. cały frontend w React, cały backend w Node.js), teraz płacą cenę w postaci wysokich kosztów skalowania.

2. Wzrost popularności lekkich rozwiązań – HTMX, Alpine.js, SolidJS zdobywają popularność tam, gdzie nie potrzebujemy pełnego SPA, ale interaktywności.

3. Architektura oparta na funkcjach, nie na technologiach – zamiast „frontend team” i „backend team”, powstają zespoły odpowiedzialne za konkretne funkcje biznesowe (np. zespół płatności, zespół rekomendacji), które same wybierają najlepsze narzędzia do swoich zadań.

Podsumowanie: framework jako środek, nie cel

Największy błąd, jaki widzę w polskim IT, to traktowanie wyboru frameworka jako decyzji na całe życie. To prowadzi do:

• Architektonycznej sztywności
• Wysokich kosztów zmian
• Uzależnienia od konkretnych technologii
• Problemy ze skalowaniem

Rozwiązanie? Pragmatyzm technologiczny. Framework to narzędzie, które ma rozwiązać konkretne problemy. Gdy przestaje to robić efektywnie – czas na zmianę lub uzupełnienie innymi narzędziami.

W JurskiTech.pl pomagamy firmom projektować architektury, które rosną wraz z biznesem, a nie blokują go. Klucz to zrozumienie, że żaden framework nie jest panaceum – to po prostu jeden z wielu narzędzi w arsenale współczesnego developera. Najważniejsze to wiedzieć, kiedy go użyć, a kiedy sięgnąć po coś innego.

Pamiętaj: Twoja wartość jako zespołu nie leży w znajomości konkretnego frameworka, ale w umiejętności rozwiązywania rzeczywistych problemów biznesowych. A te rzadko mają preferencje technologiczne.