Jak nadmierna standaryzacja frameworków niszczy skalowalność aplikacji

W ciągu ostatnich dwóch lat obserwuję niepokojący trend w polskich firmach technologicznych: zespoły developerskie coraz częściej traktują frameworki frontendowe i backendowe jak religię, a nie narzędzia. To prowadzi do sytuacji, w której technologia dyktuje biznesowi, co może zrobić, a nie odwrotnie. W JurskiTech widzimy to regularnie podczas audytów istniejących systemów – piękne, jednolite kody, które nie potrafią obsłużyć nowych wymagań biznesowych bez miesięcznych refaktoryzacji.

Dlaczego standaryzacja przestała być świętym Graalem?

Pamiętam projekt z 2021 roku, gdzie klient – średniej wielkości marketplace – miał cały frontend w React z dokładnie tym samym stackiem technologicznym: Redux, Material-UI, określona struktura folderów. Gdy przyszła potrzeba dodania modułu aukcyjnego na żywo z WebSocketami, okazało się, że przyjęta architektura kompletnie nie przewiduje takiego scenariusza. Zespół spędził 3 tygodnie na dostosowywaniu istniejących rozwiązań zamiast wybrać właściwe narzędzie do zadania.

To nie jest odosobniony przypadek. W 2023 roku audytowaliśmy platformę e-learningową, gdzie backend w całości oparto na Django. Gdy firma chciała dodać rekomendacje oparte o machine learning, zespół próbował na siłę użyć Django do zadań, do których framework ten nie był stworzony. Efekt? System rekomendacji działał 10x wolniej niż konkurencja i zużywał nieproporcjonalnie dużo zasobów.

3 rzeczywiste scenariusze, które widzimy na rynku

1. Monolity frontendowe w React

Polskie startupy technologiczne często zaczynają od Reacta – słusznie, to dobre narzędzie. Problem zaczyna się, gdy cała aplikacja musi być w React, nawet części, które powinny być statyczne. Widzieliśmy sklep e-commerce, gdzie strona produktu (głównie statyczna treść) była renderowana po stronie klienta, co dawało LCP powyżej 4 sekund. Gdy zaproponowaliśmy hybrydowe podejście (Next.js z ISG), zespół odmówił, bo „odchodzimy od standardu”.

2. Backend jako więzienie architektoniczne

W pracy z jedną z platform SaaS dla branży budowlanej natknęliśmy się na ciekawe zjawisko: cały backend w Spring Boot, ale część modułów (jak generowanie ofert PDF) byłaby 5x wydajniejsza w Go. Zespół jednak trzymał się standardu, bo „łatwiej utrzymać jeden stack”. Roczny koszt dodatkowych serwerów: około 40 000 zł. Czas potrzebny na przepisanie modułu do Go: 2 tygodnie.

3. „Frameworkowe” podejście do problemów biznesowych

Najbardziej niebezpieczny scenariusz: wybór technologii dyktuje możliwości produktu. W 2024 roku konsultowaliśmy się z fintechem, który chciał dodać funkcjonalność analizy transakcji w czasie rzeczywistym. Zespół backendowy proponował rozwiązanie oparte o ich standardowy stack (Node.js + PostgreSQL), podczas gdy problem wręcz wołał o specjalizowane narzędzie (Apache Flink lub podobne). Biznes nie dostał optymalnego rozwiązania, bo technologia narzuciła ograniczenia.

Jak rozpoznać, że Twoja standaryzacja stała się problemem?

Na podstawie dziesiątek audytów i wdrożeń wyodrębniliśmy kilka sygnałów ostrzegawczych:

1. Nowe funkcje wymagają nieproporcjonalnie dużo pracy – jeśli dodanie prostej funkcjonalności zajmuje tygodnie zamiast dni, bo musisz ją „wpasować” w istniejącą architekturę

2. Zespół unika oczywistych technologicznych rozwiązań – słyszysz „tego nie zrobimy, bo nie mamy w tym doświadczenia” zamiast „to dobre rozwiązanie, nauczymy się go”

3. Wydajność spada z każdą nową funkcją – system staje się coraz wolniejszy, mimo że dodajesz nowe serwery

4. Koszty infrastruktury rosną wykładniczo – a nie liniowo wraz ze wzrostem ruchu

Praktyczne podejście: architektura jako zestaw narzędzi, nie religia

W JurskiTech stosujemy podejście, które nazywamy „pragmatyczną architekturą”. Oto jak to działa w praktyce:

Zasada właściwego narzędzia

Każdy komponent systemu wybieramy na podstawie:

• Wymagań biznesowych (co musi robić?)
• Oczekiwanej skali (ilu użytkowników? jakie obciążenie?)
• Kompetencji zespołu (czy możemy się tego nauczyć?)
• Kosztów utrzymania (nie tylko developmentu!)

Przykład z naszego projektu: platforma do zarządzania flotą pojazdów. Frontend główny: React (duża interaktywność). Panel administracyjny: Vue (zespół miał w tym doświadczenie). Generowanie raportów: serverless functions w Pythonie (najlepsze biblioteki do danych). Każda część używa najlepszego narzędzia do swojego zadania.

Kontrakty, nie implementacje

Kluczowe jest zdefiniowanie jasnych interfejsów między modułami. Jeśli moduł A komunikuje się z modułem B przez dobrze zdefiniowane API, nie ma znaczenia, w czym każdy z nich jest napisany. Widzieliśmy system, gdzie moduł płatności w Java współpracował z modułem zamówień w Node.js przez REST API – działało bezproblemowo przez 3 lata.

Regularne przeglądy architektoniczne

Co kwartał warto zadać pytania:

• Czy któraś część systemu stała się wąskim gardłem?
• Czy pojawiły się nowe technologie, które lepiej rozwiązują nasze problemy?
• Czy koszty utrzymania którejś części są nieproporcjonalnie wysokie?

Case study: platforma B2B, która odzyskała skalowalność

W 2023 roku rozpoczęliśmy współpracę z platformą B2B w branży fashion. System miał 4 lata, całość w Ruby on Rails, zaczynał mieć problemy z wydajnością przy 500+ jednoczesnych użytkownikach.

Zamiast przepisywać całość (co sugerowali inni dostawcy), przeprowadziliśmy analizę:

1. Zidentyfikowaliśmy hot spoty – moduł wyszukiwania produktów (40% czasu odpowiedzi)
2. Wybraliśmy specjalizowane rozwiązanie – Elasticsearch dla wyszukiwania
3. Stopniowa migracja – 2 tygodnie na wdrożenie, testy A/B

Efekty po 3 miesiącach:

• Czas odpowiedzi wyszukiwania: z 1200ms do 80ms
• Koszty serwerów: spadek o 30%
• Satysfakcja użytkowników: wzrost o 22% (metryki NPS)

Kluczowe było to, że nie porzuciliśmy całego stacku – ulepszyliśmy tylko część, która tego wymagała.

Wnioski dla liderów technologicznych

1. Technologia służy biznesowi, nie odwrotnie – jeśli framework ogranicza rozwój produktu, to framework jest problemem

2. Różnorodność nie jest wrogiem – dobrze zarządzana różnorodność technologiczna daje elastyczność

3. Inwestuj w abstrakcje, nie w implementacje – dobre API pozwala zmieniać technologie bez wpływu na cały system

4. Mierz rzeczywiste koszty – nie tylko developmentu, ale też utrzymania i skalowania

W nadchodzących latach, z rosnącymi wymaganiami użytkowników i konkurencją, firmy które potrafią elastycznie dobierać technologie do problemów będą miały przewagę. Standaryzacja ma sens tam, gdzie redukuje koszty i ryzyko – ale nie może stać się celem samym w sobie.

W JurskiTech pomagamy firmom znaleźć tę równowagę: wykorzystać zalety standaryzacji tam, gdzie to ma sens, ale nie dać się uwięzić w technologicznych szufladkach. Bo w końcu chodzi o to, żeby systemy pomagały firmom rosnąć, a nie ograniczały ich możliwości.