W ci\u0105gu ostatnich pi\u0119ciu lat obserwuj\u0119 w polskich i europejskich firmach IT niepokoj\u0105cy trend: zespo\u0142y developerskie coraz cz\u0119\u015bciej standardyzuj\u0105 swoje stacki technologiczne wok\u00f3\u0142 jednego, dw\u00f3ch popularnych framework\u00f3w. Na pierwszy rzut oka to rozs\u0105dne podej\u015bcie \u2013 ujednolicenie technologii zmniejsza koszty szkole\u0144, u\u0142atwia rekrutacj\u0119 i przyspiesza development. Problem pojawia si\u0119 wtedy, gdy ta standaryzacja staje si\u0119 dogmatem, a nie narz\u0119dziem. W praktyce widz\u0119, jak firmy trac\u0105 miliony z\u0142otych na utrzymaniu aplikacji, kt\u00f3re nie mog\u0105 si\u0119 skalowa\u0107, bo ich architektura jest zak\u0142adnikiem wybranego frameworku.<\/p>\n
W ma\u0142ych startupach i m\u0142odych projektach wyb\u00f3r jednego frameworku to cz\u0119sto konieczno\u015b\u0107. Zesp\u00f3\u0142 3-5 developer\u00f3w nie ma czasu ani zasob\u00f3w, \u017ceby utrzymywa\u0107 r\u00f3\u017cne technologie. Problem zaczyna si\u0119 w momencie skalowania \u2013 zar\u00f3wno zespo\u0142u, jak i samej aplikacji. Kiedy firma ro\u015bnie do 20-30 developer\u00f3w, a aplikacja obs\u0142uguje dziesi\u0105tki tysi\u0119cy u\u017cytkownik\u00f3w, architektura zaprojektowana pod konkretny framework zaczyna pokazywa\u0107 swoje ograniczenia.<\/p>\n
Ostatnio konsultowa\u0142em projekt e-commerce, kt\u00f3ry startowa\u0142 z Reactem i Node.js. Przez pierwsze dwa lata wszystko dzia\u0142a\u0142o idealnie. Problem pojawi\u0142 si\u0119, gdy firma wesz\u0142a na rynek mi\u0119dzynarodowy i musia\u0142a obs\u0142ugiwa\u0107 jednocze\u015bnie 50 tysi\u0119cy sesji na minut\u0119. React Server Components wydawa\u0142y si\u0119 rozwi\u0105zaniem, ale ich implementacja w istniej\u0105cej architekturze wymaga\u0142a przepisania 60% kodu frontendowego. Zesp\u00f3\u0142 przez 8 miesi\u0119cy walczy\u0142 z wydajno\u015bci\u0105, zanim zdecydowa\u0142 si\u0119 na cz\u0119\u015bciowe przeprojektowanie architektury.<\/p>\n
Frameworki s\u0105 projektowane z okre\u015blonymi za\u0142o\u017ceniami. React \u015bwietnie sprawdza si\u0119 w aplikacjach z du\u017c\u0105 ilo\u015bci\u0105 interakcji u\u017cytkownika, ale gorzej radzi sobie z renderingiem statycznych tre\u015bci na du\u017c\u0105 skal\u0119. Vue.js ma \u015bwietn\u0105 krzyw\u0105 uczenia si\u0119, ale jego ekosystem jest mniejszy ni\u017c Reacta. Angular oferuje kompleksowe rozwi\u0105zanie, ale jest ci\u0119\u017cki i ma\u0142o elastyczny.<\/p>\n
Kiedy biznes zmienia kierunek \u2013 na przyk\u0142ad decyduje si\u0119 na wdro\u017cenie funkcji w czasie rzeczywistym, rozszerzenie o aplikacj\u0119 mobiln\u0105 czy integracj\u0119 z systemami legacy \u2013 zesp\u00f3\u0142 technologiczny cz\u0119sto okazuje si\u0119 zak\u0142adnikiem swojego stacka. Widzia\u0142em projekt, w kt\u00f3rym pr\u00f3ba dodania funkcji chat real-time do aplikacji Reactowej wymaga\u0142a implementacji zewn\u0119trznych bibliotek, kt\u00f3re konfliktowa\u0142y z istniej\u0105cym stanem aplikacji. Ostatecznie zesp\u00f3\u0142 sp\u0119dzi\u0142 3 miesi\u0105ce na pracy around’ach zamiast 2 tygodni na czystej implementacji w odpowiedniej technologii.<\/p>\n
Ka\u017cdy framework ma swoje limity skalowania. W Node.js problemem staje si\u0119 single-threaded architecture przy obliczeniach CPU-intensive. W Django ORM mo\u017ce sta\u0107 si\u0119 w\u0105skim gard\u0142em przy z\u0142o\u017conych zapytaniach do du\u017cych baz danych. W React Virtual DOM staje si\u0119 problemem przy bardzo dynamicznych interfejsach z tysi\u0105cami komponent\u00f3w.<\/p>\n
W jednym z projekt\u00f3w SaaS, kt\u00f3ry konsultowa\u0142em, zesp\u00f3\u0142 u\u017cywa\u0142 Django REST Framework do budowy API. Przy 10 tysi\u0119cy u\u017cytkownik\u00f3w wszystko dzia\u0142a\u0142o p\u0142ynnie. Przy 100 tysi\u0119cy zacz\u0119\u0142y si\u0119 problemy z wydajno\u015bci\u0105 endpoint\u00f3w. Analiza pokaza\u0142a, \u017ce ORM Django generowa\u0142 nieoptymalne zapytania SQL, kt\u00f3rych optymalizacja wymaga\u0142a obej\u015bcia frameworka. Zesp\u00f3\u0142 musia\u0142 przepisa\u0107 kluczowe cz\u0119\u015bci aplikacji u\u017cywaj\u0105c czystego SQL i asynchronicznych worker\u00f3w, co zaj\u0119\u0142o 6 miesi\u0119cy i kosztowa\u0142o firm\u0119 oko\u0142o 500 tysi\u0119cy z\u0142otych.<\/p>\n
Najbardziej ukryty koszt to ten, kt\u00f3rego nie wida\u0107: funkcje, kt\u00f3rych nie zbudujesz, bo framework ich nie wspiera; optymalizacje, kt\u00f3rych nie wdro\u017cysz, bo architektura na to nie pozwala; nowe technologie, kt\u00f3rych nie przetestujesz, bo \u201eu nas si\u0119 tak nie robi\u201d.<\/p>\n
W 2023 roku pracowa\u0142em z fintechem, kt\u00f3ry chcia\u0142 wdro\u017cy\u0107 WebAssembly do oblicze\u0144 finansowych w przegl\u0105darce. Ich stack frontendowy (React + Redux) nie by\u0142 kompatybilny z efektywn\u0105 integracj\u0105 WebAssembly. Zamiast 2-tygodniowego proof of concept, zesp\u00f3\u0142 potrzebowa\u0142 3 miesi\u0119cy na przygotowanie \u015brodowiska i przepisanie cz\u0119\u015bci logiki. W mi\u0119dzyczasie konkurencja wdro\u017cy\u0142a podobne rozwi\u0105zanie i przej\u0119\u0142a cz\u0119\u015b\u0107 ich klient\u00f3w.<\/p>\n
Zamiast pyta\u0107 \u201eCzy mo\u017cemy to zrobi\u0107 w naszym frameworku?\u201d, zacznij pyta\u0107 \u201eJaka technologia najlepiej rozwi\u0105\u017ce ten problem?\u201d. To fundamentalna r\u00f3\u017cnica w my\u015bleniu. W JurskiTech.pl przy projektowaniu architektury zawsze zaczynamy od wymaga\u0144 biznesowych, a nie od naszych ulubionych technologii.<\/p>\n
Przyk\u0142ad z naszego projektu: klient potrzebowa\u0142 platformy do zarz\u0105dzania tre\u015bci\u0105 z edytorem WYSIWYG w czasie rzeczywistym dla wielu u\u017cytkownik\u00f3w. Zamiast forsowa\u0107 Reacta (kt\u00f3ry ma problemy z collaborative editing), zaproponowali\u015bmy hybrydowe rozwi\u0105zanie: Vue.js dla interfejsu u\u017cytkownika (lepsza reaktywno\u015b\u0107) + Node.js z Socket.io dla komunikacji real-time + Quill.js jako edytor. Ka\u017cda technologia robi\u0142a to, w czym jest najlepsza.<\/p>\n
Kluczem do skalowalno\u015bci jest separacja warstw aplikacji. Business logic powinien by\u0107 niezale\u017cny od frameworka. U\u017cywamy wzorca Clean Architecture lub Hexagonal Architecture, gdzie core aplikacji (domena biznesowa) jest napisany w czystym JavaScript\/TypeScript\/Pythonie, a frameworki s\u0105 tylko adapterami.<\/p>\n
W praktyce wygl\u0105da to tak, \u017ce mo\u017cemy wymieni\u0107 framework frontendowy z Reacta na Vue.js w ci\u0105gu 2-3 miesi\u0119cy, bez dotykania logiki biznesowej. To daje firmom nieprawdopodobn\u0105 elastyczno\u015b\u0107 w odpowiedzi na zmieniaj\u0105ce si\u0119 wymagania rynku.<\/p>\n
Co kwarta\u0142 przeprowadzamy z klientami przegl\u0105d architektury. Zadajemy pytania:<\/p>\n
To nie jest poszukiwanie problem\u00f3w, gdzie ich nie ma. To \u015bwiadome zarz\u0105dzanie ryzykiem technologicznym. W jednym przypadku takie przegl\u0105dy pozwoli\u0142y firmie zaoszcz\u0119dzi\u0107 300 tysi\u0119cy z\u0142otych rocznie na kosztach infrastruktury, poprzez stopniow\u0105 migracj\u0119 cz\u0119\u015bci mikroserwis\u00f3w z Node.js na Go.<\/p>\n
Przyk\u0142ad z naszego portfolio: firma z bran\u017cy logistycznej mia\u0142a system zarz\u0105dzania flot\u0105 w Angularze. Kiedy zdecydowali si\u0119 doda\u0107 funkcj\u0119 \u015bledzenia GPS w czasie rzeczywistym dla 5000 pojazd\u00f3w, Angular okaza\u0142 si\u0119 zbyt ci\u0119\u017cki. Zamiast rozbudowywa\u0107 istniej\u0105c\u0105 aplikacj\u0119, zbudowali\u015bmy osobny mikroserwis w Node.js + WebSockets, kt\u00f3ry specjalizowa\u0142 si\u0119 tylko w \u015bledzeniu. Po roku okaza\u0142o si\u0119, \u017ce to rozwi\u0105zanie jest 10x bardziej wydajne i 3x ta\u0144sze w utrzymaniu ni\u017c rozbudowa g\u0142\u00f3wnej aplikacji.<\/p>\n
Najwi\u0119kszy b\u0142\u0105d, jaki widz\u0119 w polskich firmach IT, to traktowanie framework\u00f3w jako celu samego w sobie. Developerzy chc\u0105 \u201erobi\u0107 w Reactie\u201d zamiast \u201erozwi\u0105zywa\u0107 problemy biznesowe\u201d. Product ownerzy pytaj\u0105 \u201eCzy mo\u017cemy to zrobi\u0107 w naszej technologii?\u201d zamiast \u201eJaka technologia najlepiej rozwi\u0105\u017ce ten problem?\u201d.<\/p>\n
Framework to tylko narz\u0119dzie. Jak m\u0142otek w warsztacie. Mo\u017cesz nim wbi\u0107 gw\u00f3\u017ad\u017a, ale nie u\u017cyjesz go do przykr\u0119cenia \u015bruby. Im szybciej firmy zrozumiej\u0105 t\u0119 prost\u0105 zasad\u0119, tym mniej b\u0119d\u0105 traci\u0107 na nieelastycznych architekturach.<\/p>\n
W JurskiTech.pl nigdy nie zaczynamy projektu od pytania o technologie. Zaczynamy od pytania: \u201eJaki problem biznesowy rozwi\u0105zujemy?\u201d. Dopiero potem dobieramy narz\u0119dzia. Czasem to b\u0119dzie jeden framework, czasem kilka. Czasem czysty JavaScript, czasem specjalistyczne biblioteki. Elastyczno\u015b\u0107 technologiczna to nie chaos, to \u015bwiadoma strategia budowania rozwi\u0105za\u0144, kt\u00f3re rosn\u0105 razem z biznesem.<\/p>\n
Ostatnia obserwacja: firmy, kt\u00f3re najszybciej si\u0119 rozwijaj\u0105 na rynku, to te, kt\u00f3re traktuj\u0105 technologi\u0119 instrumentalnie. Ich stack technologiczny zmienia si\u0119 \u015brednio co 2-3 lata, ale ich produkty s\u0105 stabilne i skalowalne. Firmy, kt\u00f3re kurczowo trzymaj\u0105 si\u0119 swoich framework\u00f3w, cz\u0119sto zostaj\u0105 w tyle \u2013 nie dlatego, \u017ce ich technologia jest z\u0142a, ale dlatego, \u017ce nie potrafi\u0105 si\u0119 dostosowa\u0107 do zmieniaj\u0105cego si\u0119 \u015bwiata.<\/p>\n
Je\u015bli patrzysz na sw\u00f3j stack technologiczny i widzisz, \u017ce ostatnia powa\u017cna zmiana by\u0142a 3 lata temu \u2013 to mo\u017ce by\u0107 czerwona flaga. Technologia w IT zmienia si\u0119 co 18-24 miesi\u0105ce. Twoja architektura powinna pozwala\u0107 na ewolucj\u0119, a nie blokowa\u0107 j\u0105 w imi\u0119 standaryzacji.<\/p>\n","protected":false},"excerpt":{"rendered":"
Jak nadmierna standaryzacja framework\u00f3w niszczy skalowalno\u015b\u0107 aplikacji W ci\u0105gu ostatnich pi\u0119ciu lat obserwuj\u0119 w polskich i europejskich firmach IT niepokoj\u0105cy trend: zespo\u0142y developerskie coraz cz\u0119\u015bciej standardyzuj\u0105 swoje stacki technologiczne wok\u00f3\u0142 jednego, dw\u00f3ch popularnych framework\u00f3w. Na pierwszy rzut oka to rozs\u0105dne podej\u015bcie \u2013 ujednolicenie technologii zmniejsza koszty szkole\u0144, u\u0142atwia rekrutacj\u0119 i przyspiesza development. Problem pojawia si\u0119<\/p>\n","protected":false},"author":2,"featured_media":1292,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[239,334,336,312,335],"class_list":["post-1293","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-warto-wiedziec","tag-business-flexibility","tag-frameworks","tag-modern-web-development","tag-scalability","tag-software-architecture"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1293","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=1293"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1293\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media\/1292"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1293"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1293"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1293"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}