Mateusz: Cześć! Witamy w kolejnym odcinku podcastu Piwnica IT. Po ostatnich naszych przygodach z WET, DRY, AHA, z SSR, SSG, SPA, MPA, z monorepo i polirepo - dzisiaj przyszedł czas na temat, który w zasadzie wbił nam się trochę jak klin, ale bardzo dobrze, ponieważ jest dosyć ciekawy i szczególnie w sytuacji obecnie dynamicznie rozwijającego się rynku usług frontendowych, myślimy, że jest to temat bardzo wciągający. Mianowicie dzisiaj chcieliśmy porozmawiać o Next. NextJS jako framework, który wprowadza sporo zamieszania na rynku usług IT. Myślę, że to zamieszanie jest bardzo dobre. I dzięki temu tak naprawdę wprowadza troszeczkę może świeżości, troszeczkę dynamiczności do tego, jak ten rynek się ostatnimi laty rozwijał. Cześć Wojtku.

Wojtek: Cześć Mateuszu.

Mateusz: Powiedziałem na samym początku, że chciałbym, żebyśmy dzisiaj porozmawiali o Next. Jak ten temat Ci leży?

Wojtek: Jest to zdecydowanie ciekawy temat i też jak najbardziej chciałbym o tym z Tobą porozmawiać, Mateuszu. Poznać Twoją opinię na temat samego Nexta ale w ogóle podejścia do tej drogi, którą zmierzamy jako developerzy Reactowi. Sam React w swojej dokumentacji w tym nowym wydaniu już poleca Nexta razem z tymi nowymi frameworkami SSR jako podstawę wszystkich nowych projektów.

Mateusz: To prawda, polecają. Warto też spojrzeć na to, jak to się zmieniło na przestrzeni ostatnich lat. Bo jeżeli cofniemy się troszeczkę w czasie, to zobaczymy, że React jak zaczynał, to tak naprawdę on bardzo mocno polecał własny framework. Własny framework do budowania aplikacji opartej o Reacta, tutaj mam na myśli Create React App. O ile można to nazwać mini frameworkiem, jakimś narzędziem, który tak naprawdę pomagał w budowaniu tych aplikacji. Ale jak wiemy Create React App już nie jest, jakby to ładnie powiedzieć, nie jest na topie. Teraz można powiedzieć, że tak naprawdępowoli nam odchodzi w niepamięć i nawet sam React, który w zasadzie jest twórcą CRA doprowadził do tego, że poleca narzędzia zewnętrzne - Nexta. Dlaczego poleca tego Nexta? Co w nim jest takiego ciekawego, że Next rzeczywiście jest fajniejszy niż CRA czy chociażby inne narzędzia, które są do tej pory dostępne na rynku i które służą dokładnie do tych samych rzeczy.

Wojtek: To znaczy myślę, że Next jak i pozostałe tego typu frameworki symbolizują niejako moim zdaniem kierunek, w którym cały team Reactowy chce się poruszać w nadchodzącej przyszłości. Czyli odejście od wykonywania całego kodu u klienta w przeglądarce, niezależnie czy to jest przeglądarka desktopowa czy przeglądarka mobilna, właśnie w kierunku takiego podejścia hybrydowego, gdzie część jest wykonywana na serwerze, gdzie chcą wykorzystać ten serwer najlepiej jak potrafimy, skorzystać ze wszystkich dobrodziejstw, które daje nam wykonywanie JavaScriptu na serwerze i wykorzystanie tych rzeczy, które daje nam wykonywanie instrukcji.

Mateusz: Przypomina mi się nasza rozmowa SPA i SSR. Ten koncept aplikacji hybrydowych, o którym wspomniałeś fajnie się zazębia, bo te aplikacje klienckie - są trochę passe. Można powiedzieć, że w tym momencie mają swoje wady, o których już mówiliśmy. Odsyłamy też do naszej poprzedniej rozmowy na ten temat. Natomiast - myślisz, że aplikacje hybrydowe są przyszłością? Czyli tak naprawdę mieszanie troszeczkę tej części klienckiej z tą częścią serwerową?

Wojtek: Czy są przyszłością tak w 100%, że będziemy korzystać tylko z nich? Myślę, że nie jest to nasza przyszłość i myślę, że zdecydowanie jest to podejście do jakiegoś zbioru problemów, które dzięki tej technologii hybrydowej, którą tutaj tak określiliśmy, możemy rozwiązać. Ale myślę, że to nie jest klucz do wszystkiego. Chociaż symbolizuje to pewną ciekawą drogę, którą będziemy się w najbliższym czasie poruszać jako frontendowi developerzy. I tutaj też, tak jak Ci wspominałem przed nagraniem tego odcinka jestem ciekawy Twojego zdania na temat stawania się trochę backend developerem będąc frontend developerem i w ogóle umiejscowienia tego frameworku typu NextJS ale i tych pozostałych, o których wspominaliśmy - właśnie w tych takich standardowych granicach, czy też w takich standardowych ramach, w których umieszczamy siebie i frameworki, bo mi ciężko jest go umiejscowić w jednym albo drugim miejscu, bo zdecydowanie nie jest to framework frontendowy, ale też nie jest to framework backendowy. Chciałbym poznać Twoje zdanie. Co myślisz o tym? Po pierwsze o stawaniu się takim backend developerem na frontendzie? I po drugie właśnie co myślisz o w ogóle tego typu frameworkach - takich backendowo - frontendowych?

Mateusz: W ogóle zacząłbym od tego, żeby spróbować zdefiniować swoją pozycję na rynku. Czy ja jestem w ogóle frontend developerem czy backend developerem czy może fullstackiem? I pomimo, że uważam, że trudno nazwać siebie fullstackiem, bo tak naprawdę każdy fullstack zawsze ma jakieś odchylenie w stronę albo bardziej frontendowych technologii, albo backendowych. Natomiast ja przez całe już ostatnie lata definiowałem siebie jako jako frontend developer. I tutaj musiałbym zdefiniować czym jest frontend w naszym rozumieniu, bo w wielu opracowaniach jak spojrzymy na różnego rodzaju definicje słowa frontend czy frontend development znajdziemy coś w stylu, że jest to programista, inżynier, który zapewnia obsługę warstwy wizualnej. Szeroko rozumianej. Bo tak jak powiedziałeś, dzisiejszy frontend to nie jest tylko warstwa wizualna, bo to nie jest CSS, to nie jest HTML. To jest też bardzo często - logika, logika przekształcania danych z jednego miejsca w drugie. To jest też kwestia doboru architektury i pracowania w tej architekturze. Mamy dostęp do architektur, które nie zawsze są wykorzystywane na backendzie, a które są specyficzne per frontend. Frontend sam w sobie przez to, w jakim środowisku operujemy, czyli w środowisku przeglądarki, sam w sobie jest dość dość złożony i tak naprawdę może nawet nietypowy dla programistów, którzy mają na co dzień kontakt z backendem. Często się mówiło kiedyś i pewnie to też dzisiaj powtarza się ludziom, którzy chcą wejść do branży, że jeżeli lubisz mieć efekt szybko i lubisz widzieć, co się dzieje, to, co powstaje, to co tworzysz - to frontend jest dla Ciebie. To już nie jest do końca prawda, mi się wydaje. Wydaje mi się, że dzisiejszy frontend to jest dużo częściej większy nacisk na logikę, na budowanie, na przekształcenia danych, na optymalizację i zarządzanie wydajnością tych aplikacji. Frontend robi dzisiaj dużo więcej niż kiedyś. W większości przypadków nadal jest to ustalenie kontraktu z backendem. Ustawienie jakie dane backend ma nam zwrócić i my te dane już bez przekształceń sobie po prostu musimy odpowiednio wyświetlić, ale nadal te dane musimy umieścić w jakiejś architekturze, jakiejś strukturze i po prostu przekształcić tak, żeby to było w miarę optymalne, żeby to po prostu dobrze funkcjonowało. Warto tutaj podkreślić, że te nasze aplikacje się rozrastają. Stają się, takie, że tak powiem, nasycone, czasami może nawet przeładowane. I teraz te aplikacje muszą być po prostu sprawne. Więc wydaje mi się, że frontend w rozumieniu opracowywania warstwy wizualnej już się skończył. Bardziej definiował bym siebie jako właśnie software engineer, czyli ktoś kto pracuje nad oprogramowaniem. Ale czy ja pracuję na warstwie właśnie wizualnej, czy na warstwie logiki to już jest mniej ważne, bo w zasadzie scope pracy frontend developera ogranicza się najczęściej do aplikacji, która jest odpowiedzialna za dostarczenie tej warstwy wizualnej, ale to nie jest jej jedyne zadanie, które w ramach całej aplikacji i całego systemu wykonuje.

Wojtek: OK, ale myślałem tutaj o czymś innym. Rozumiem, że te ramy nie są takie oczywiste jak kiedyś i zgadzam się z Tobą, ale myślę, że możemy stwierdzić oboje, że pisanie SQLa jest to rzecz backendowa. Przynajmniej do tej pory było. Nie zdarzyło Ci się jako frontend developer pisać SQLa?

Mateusz: Zdarzyło, ale nie w aplikacjach frontendowych.

Wojtek: To tak, to o to mi chodzi. No właśnie. A teraz dochodzimy do takiego momentu, gdzie razem z tym nowym updatem Next czyli Next'a 13.4 dochodzimy do takiego momentu, gdzie w naszych komponentach frontendowych możemy napisać backendowe query.

Mateusz: Możemy. No i to jest właśnie ten mix, o którym wspominasz, bo Next, zgodziłbym się w stu procentach z Tobą, że Next nie będzie frameworkiem, który jest czysto frontendowy i nigdy nie był. Nawet nie chodzi o tą wersję 13.4, tylko poprzednie wersje już pokazywały to, że ten framework daje spore możliwości obsługiwania chociażby requestów backendowych. Mogłeś stworzyć własne API już od samego początku istnienia Next. Mogłeś ukryć jakąś logikę, która zazwyczaj była ukrywana po stronie backendowej. Mogłeś ukryć ją w swoim kodzie w aplikacji frontendowej, bo docelowo Next działał wówczas też jako aplikacja backendowa.

Wojtek: Tak, to prawda, że teraz jest to jeszcze bardziej dobitne. W związku z tym nowym folderem App i tego, że możemy łączyć ze sobą te funkcje i teraz bezpośrednio w samym komponencie, za pomocą tego magicznego useServer możemy zdefiniować funkcję backendową w samym komponencie.

Mateusz: No dobra, mam inne pytanie, bo to, że tak się dzieje, że Next w tym kierunku idzie to jest w zasadzie fakt. Tak się po prostu dzieje od samego początku istnienia Nexta. Patrząc na środowisko frontendowe ludzie to akceptują, lubią, w tym pracują. Sam pracuję z Nextem, moja strona jest w tym napisana i mi się bardzo dobrze z tym pracuje. Doceniam to, że tam jest dużo możliwości, pisania kodu backendowego. W zasadzie podoba mi się to, że wprowadzono bazy danych, ale czy to jest dobry kierunek? Czy to na pewno jest ten kierunek, w którym to powinno iść? Czy frontend, który w zasadzie ma za zadanie dostarczać tą warstwę wizualną - powinien mieć możliwość wykonywania i tworzenia query na bazie? W moim odczuciu to już jest troszeczkę krok dalej. Pytanie czy to krok może za daleko? Wydaje mi się, że ten bardziej klarowny podział, gdzie aplikacja tworzona po stronie backendu wykonywała zapytania do bazy i tylko ona je wykonywała miało więcej sensu niż teraz posiadanie takich możliwości w aplikacji frontendowej. I teraz pytanie czy taka aplikacja Next będzie potrzebowała dodatkowy backend? Bo prawdopodobnie już pewnie nie do prostych rozwiązań.

Wojtek: Najpewniej nie.

Mateusz: To jest ten case. Czy to jest dobry kierunek? Czy to powinno w tę stronę iść? Bo to, że aplikacja może takie rzeczy robić, to może być przydatne. Pytanie czy powinna

Wojtek: Ale czy to nie jest troszkę odpowiedź Twoim zdaniem na te problemy o których Ty wspominałeś jeszcze przed chwilą, czyli właśnie takiego bycia fullstackiem i tego, że te granice się rozmywają itd. I właśnie dzięki takiemu frameworkowi jak Next możemy sobie stworzyć to wszystko w jednej bazie kodu. Nie mamy problemu z typowaniem, nie potrzebujemy jakichś dodatkowych ludzi dookoła dodatkowych aplikacji. Mamy tylko jedną aplikację, która jest odpowiedzialna za to wszystko od początku do końca.

Mateusz: Tylko wiesz, jak coś jest do wszystkiego, to jest do niczego. Zgodziłbym się, że jeżeli nie potrzebujemy ludzi, bo w zasadzie jeden developer może wszystko ogarnąć i w porządku. Ale z drugiej strony - po to mamy tak dużo różnych technologii, które są odpowiedzialne za różne rzeczy, ponieważ są zoptymalizowane pod konkretne zadania. Tutaj mówimy tylko i wyłącznie o Javascript - jednym języku. Nie mówimy tylko o jednym frameworku Next, który jeszcze jest dość mocno uzależniony od firmy, która go tworzy, czyli Vercel. Już abstrahując, bo możemy sobie tego Next naszego postawić gdziekolwiek chcemy, ale Vercel też tutaj odgrywa dość dużą rolę i daje dość dużo narzędzi po to, żeby do tego Next jeszcze bardziej przekonać. A z drugiej strony, czy JavaScript jest takim rzeczywiście narzędziem, które jest idealne do wszystkiego? Gdyby tak było, to przecież wszyscy by w tym pisali, a wiemy, że tak nie jest. Tych języków, które są na rynku jest bardzo, bardzo, bardzo dużo. Nawet Kobol, który już pewnie ma z 70 lat, do dnia dzisiejszego jest dość mocno wykorzystywany czy to w bankomatach, czy w instytucjach finansowych i do dnia dzisiejszego jest dinozaurem wśród języków, ale nadal dość dobrze płatnym jeśli chodzi o umiejętności i dość popularny właśnie przez to, że jest tak stabilny, stały i dedykowany do tych konkretnych rozwiązań, do których został stworzony, czyli właśnie dla branży finansowej.

Wojtek: Oczywiście, że tak Mateuszu. Jeśli mamy jakieś konkretne rozwiązanie, które rozwiązuje bardzo konkretny, specyficzny problem, to będzie lepsze od podejścia od takiego generycznego.

Mateusz: Dokładnie, więc wydaje mi się, że właśnie tu jest ten problem Nexta. Czy Next zakłada, że wszystko możemy zrobić w Javascript? I to jest ok - możemy wszystko zrobić w Javascript. Pytanie czy zrobić możemy to najlepiej? Czy to nie jest po prostu tak, że powstaje opcja i powstaje nam taki hype jak powstał hype na Redux'a? Kiedy Redux się pojawił i Dan Abramov ten swój słynny wpis na Stackoverflow, zaczęła się ta cała ścieżka, gdzie Redux stał się bardzo, bardzo popularny, gdzie wszyscy chcieli tego używać i używali tego. Redux trafił do każdego projektu, niezależnie od tego, czy miał sens istnieć w danym projekcie. Nikt nie zastanawiał się nad kosztami wprowadzenia takiego globalnego zarządzania stanem. Ale tak było. Taki był czas, że po prostu jak pojawił się Redux, to praktycznie w każdym projekcie był.

Wojtek: Pamiętasz Redux Forms?

Mateusz: Tak, pamiętam dużo rzeczy z Reduxa: Redux Saga, Redux Thunki.

Wojtek: Ale w ogóle Saga była ciekawym rozwiązaniem z tymi generatorami, bardzo rzadko spotykane w programowaniu w Javascript.

Mateusz: Są takie rzeczy w Javascript, o których tak się dużo nie mówi, a które mogą służyć fajnym rzeczom np. etykiety w JS. To też ciekawe rozwiązanie, rzadko kiedy wykorzystywane. Często myli się ludziom, developerom, bo nie wiedzą o istnieniu tego, myślą, że to jest po prostu dziwny obiekt. Tak naprawdę to jest jakaś etykieta, która pozwala nam chociażby bardziej optymalnie zarządzać pętlami. To są takie niuanse języka, do których wielu ludzi nie zagląda i tak naprawdę mało kto wie, że coś takiego można zrobić. To właśnie o to chodzi, ż język to jest narzędzie. To jest narzędzie, a Next jest frameworkiem jakimś nadrzędnym, nadbudówką nad Reacta - na tą bibliotekę do zarządzania mutacjami w strukturach, która próbuje w tym momencie w moim odczuciu udowodnić, że w zasadzie programista, który zajmuje się Next może zastąpić z powodzeniem backendowca, frontendowca, a może nawet UX designera, bo gdzieś tam czytałem, że nawet jest pomysł na to, żeby wprowadzić theme'y albo już je wprowadzono.

Wojtek: W każdym razie myślę, że ciekawa opinia Mateuszu na temat tego w jaką stronę się poruszamy. Myślę, że dla mnie fajnie jest, że takie opcje udostępnia Next i rozwija się w tym kierunku. Myślę, że tak jak wspomniałem nie jest to rozwiązanie każdego problemu i Next nie będzie dobry do każdej aplikacji Reactowej, chociaż śmiem twierdzić, że będzie optymalny dla 80% aplikacji, które są tworzone aktualnie w React. Bardzo ciekawe jest to jak blisko współpracują ze sobą: team Next razem z teamem Reactowym core'wym i jak te dwa frameworki na siebie wpływają i jak siebie uzupełniają. Więc myślę, że przyszłość w tym kontekście jest dość ciekawa.

Mateusz: To jest chyba też inny case, że chyba już świat developmentu, programowania uświadomił sobie, że nie da się osiągnąć wielkich rzeczy, zrobić wielkich rzeczy w pojedynkę. Zwróć uwagę jak jeszcze mieliśmy lata 2010 - 2009 - 2008 - każda firma w Poznaniu, która robiła strony internetowe oferowała swój własny CMS. Każda budowała coś własnego, coś swojego od zera czy sprzedawali własny soft. A później pojawiło się takie zaskoczenie, że ej no przecież, własny soft jest fajne, ale jest bardzo zabuggowany, trudno go rozwijać, ciężko go utrzymywać. Ciężko napisać bardzo dobry CMS, który będzie pokrywał wymagania wielu klientów, a tak naprawdę będzie finansowany przez 10 czy 20 klientów danej firmy. Nie da się tego zrobić dobrze. Dlatego też firmy zdecydowały się w końcu na przejście właśnie na te rozwiązania od Adobe czy właśnie od Magento, od Presty czy od WordPressa. Tego się pojawiło od groma. Ale za tymi projektami stała społeczność, która dostarczała nowe pomysły, dostarczała rozwiązania popularnych błędów i dostarczała wtyczki. Tutaj obserwujemy dokładnie to samo wydaje mi się. React - za nim stoi ogromna rzesza ludzi, ale sam React chyba już zauważył, że pomimo to jest nadal tylko i wyłącznie biblioteką. A jeśli chcą zrobić coś większego, muszą wejść w jakąś kooperację z kimś, kto rzeczywiście ma szansę pomóc im wynieść ten projekt na jeszcze wyższy level. I tutaj Vercel według mnie robi świetną robotę, bo zobacz jak ta firma fajnie rośnie. Zobacz jakie fajne rzeczy dostarczają i jak dużo się zmienia w Next. Już dawno nie było takiego projektu w naszym świecie IT, który tak dynamicznie się rozwijał i tak szybko dostarczał rzeczy.

Wojtek: Zgadzam się z Tobą. W ogóle ciekawe porównanie. To tak jak z tym z Counter Strike i Half-Life, który zaczął swoje życie przecież jako mod do Half-Life. Wracając już to do naszych tematów programistycznych, zgadzam się z Tobą, chociaż myślę, że to duży plus Reacta od samego początku, że core'wy team Reacta od tej wersji szesnastej, tak na dobrą sprawę, był dość mały, ale też otwarty na to co co się dzieje w community. To było też fajnie, bardzo moim zdaniem moderowane. Dzięki temu też framework się tak nie rozrósł. Myślę, że to jest ogromny plus w porównaniu do takiego Angulara, gdzie masz tysiąc narzędzi zapewnionych przez sam framework. W React bardzo dużo rzeczy możesz wybrać samemu od routingu, który mamy dwie duże biblioteki po narzędzie do fetch'owania danych. Community bardzo mocno wzbogaca ten framework. Widzimy to tutaj ponownie na przykładzie Next.

Mateusz: Mówimy o React i traktujemy go jako powiedzmy framework czy bibliotekę. Zwał jak zwał, bo dyskusji na ten temat jest bardzo duża. Natomiast porównując Reacta do Angulara - nie wiem czy to jest najlepsze porównanie. Może lepiej porównać właśnie Nexta do Angulara? Tak jak powiedziałeś, Angular zapewnia cały zestaw narzędzi, które czynią z niego spójne narzędzie, spójny framework, który razem po prostu ma działać. Tak samo jest z Next. Next też dostarcza cały zestaw bibliotek, od fontów, poprzez obrazki i routing, skończywszy na chociażby paczkach do dynamicznego ładowania komponentów. Więc mi się wydaje, że Next'owi bliżej do frameworka czy też do stania się konkurencją dla Angulara niż React, który sam w sobie pomimo tego, że jest to po prostu biblioteka, która ma ma jakiś tam model kompozycyjny zapewnić, która dostarcza kilka fajnych API typu konteksty - to poza tym tak naprawdę w React nic nie ma. I może to był też powód, dla którego zespół core'owy Reacta postanowił właśnie znaleźć kogoś, kto im pomoże, bo trochę może utknęli. Może utknęli właśnie w tym takim rozwijaniu biblioteki. Gdzieś musieli zrobić następny krok, żeby po prostu Reacta puścić do przodu. Pojawia się bardzo dużo koncepcji nowych typu wprowadzenie chociażby React Server Components. Pojawiają się refaktoringi, pojawiała się ostatnim czasem nowa dokumentacja, która jest o wiele fajniejsza, czytelniejsza. Ten projekt żyje, on się rozwija, usuwają stare Legacy API, pojawiają się różnego rodzaju dodatki, które mają spowodować, że będzie nam się lepiej z tym pracowało. Ale w ostatecznym rozrachunku React nadal pozostawia dużo wolności, bo to jest biblioteka. Zostawia wolność, którą Ty możesz sobie samodzielnie zagospodarować tak jak chcesz. Next jest w opozycji, Next już tego nie daje. Next mówi słuchajcie, tu macie routing, tu macie images, tu macie fonts, tu macie to, tu macie tamto - to razem tworzy Nexta. Chcecie korzystać z Nexta? Korzystajcie z tego. To Wam dostarczamy.

Wojtek: Zgadzam się z Tobą Mateuszu, chociaż myślę, że w momencie kiedy jesteś autorem takiej biblioteki jak React, moim zdaniem jest to dla Ciebie idealne rozwiązanie. Ktoś testuje różne podejście do Twojej biblioteki i po przetestowaniu jej zupełnie oddzielnie, gdzieś na boku czy jeśli chodzi o jakiś routing, data fetching i tak dalej, i tak dalej - ta biblioteka może bardzo szybko ewoluować w związku z tym, że jest mała i oddzielnie są te wszystkie zależności jakieś dodatkowe i bardzo szybko możesz też dostosowywać w momencie, kiedy już dochodzi do takiego momentu, że chcesz jakoś mocno zmienić framework, tak jak w przypadku React i React Server Components, gdzie jest to ogromna zmiana w podejściu do myślenia o tej bibliotece. Żeby nie używać tutaj słowa framework. Myślenie o tej bibliotece właśnie dlatego, że jest całe community, które tworzy te wszystkie narzędzia, testuje, sprawdza co najlepiej działa, a Ty jako autor biblioteki możesz korzystać z tej całej pracy, która została zrobiona dokoła tego.

Mateusz: Jeśli mówimy o Next to musimy wspomnieć o Vercel'u i o narzędziu jakie dostarcza i tak naprawdę tej części związanej z Continuous Integration - Continuous Deployment razem z właśnie serwerem hostingowym, miejscem na hosting projektów. Fajnie zoptymalizowany pod projekty Nextowe. Gdzie tak naprawdę mamy całą analitykę, cały performance, mamy możliwość przejrzenia logów, tego, co się dzieje w naszej aplikacji, mamy możliwość poukładania sobie środowisk, stworzenie kilku. Platforma od Vercela, kiedy połączymy ją z naszym Nextem, powstaje nam bardzo potężne narzędzie, które jest w zasadzie szyte na miarę dla naszego frameworka, dla naszej aplikacji. Łącząc to z tym wszystkim, o czym mówiliśmy wcześniej, czyli tak naprawdę bazy danych, implementacje różnego rodzaju optymalizacji czy właśnie wprowadzenie theme'ów, w ostateczności może zrobienie właśnie supportu, wparcia dla rzeczy typu SEO to wszystko może funkcjonować fajnie i warto podkreślić, że Vercel chyba wie co robi. Mają bardzo fajny plan na to. Tak jak powiedziałaś, można z tym zrobić wszystko i większość wymagań projektowych te narzędzia pokryją. Sam używam prywatnie i uważam to za coś naprawdę fajnego, coś, co naprawdę daje frajdę z pracy. Możliwość tworzenia różnego rodzaju integracji chociażby ze Slackiem, z mailem. To jest po prostu coś co mega usprawnia cały proces.

Wojtek: PS. To w ogóle ciekawy model na prowadzenie firmy. Taki ciekawy pomysł na startup niejako i teraz na ogromną firmę, czyli na zapewnianie takich narzędzi dookoła jakiegoś frameworku. To takie dość nie jest standardowe podejście, co prawda teraz bardzo popularne, szczególnie w środowisku baz danych. Nie wiem czy zauważyłeś, że ostatnio zrobiło się tego bardzo dużo.

Mateusz: Mongo zawsze tak pracowało. Mogłeś korzystać z Mongo, które było schematem, który mogłeś sobie wykorzystywać jak chciałeś. Natomiast jak chciałeś mieć to fajnie zrobione to firma, ta która zajmuje się Mongo, dostarcza Tobie Mongo Atlas, chyba tak się nazywało to narzędzie, i tam miałeś wszystkie narzędzia związane z Mongo i do takich rzeczy, że nawet byś nie pomyślał, że to potrzebujesz. SQL - chyba nie ma nic takiego, nie?

Wojtek: Jest pełno, oczywiście. Jest chociażby Postgres od Nexta, które teraz się pojawiło, ale tego typu narzędzi...

Mateusz: PostgreSQL sensie nie jest narzędziem.

Wojtek: Tak, ale w wydaniu takich rzeczy typu database as a service, czyli że nie hostujesz stricte bazy danych, tylko masz taki interfejs i to wszystko dzieje się trochę poza Tobą. Wszystkie te rzeczy typu tworzenie tabel, jakby nie zajmuje się backendem. Koniec końców masz właśnie jakiś prosty interfejs webowy czy nawet nie prosty, ale pewnie relatywnie w większości przypadków dość skomplikowany, gdzie możesz sobie wszystko ustawić. Właśnie interakcje z samą bazą danych działają trochę jak z Firebase'em. Czyli masz jakiś API czy SDK i w taki sposób komunikujesz się z tą swoją bazą danych. Nie komunikujesz się bezpośrednio za pomocą SQLa i nie masz tych wszystkich rzeczy, które związane są z hostowaniem, migracjami itd. Tylko to wszystko jest zapewnione właśnie przez te firmy. Taka pierwsza, która przychodzi mi do głowy to jest Super Base.

Mateusz: Nie, nie słyszałem, ale pamiętam, że nie wydaje mi się, żeby to było coś nowego, bo pamiętam, że jeszcze w 2015 roku był taki projekt Backend.io, który dokładnie robił to samo. Czyli idea była taka, że kupujesz backend as a service. Wyklikujesz sobie całą strukturę, wszystkie tabele bazodanowe, relacje pomiędzy nimi. Wyklikujesz sobie całą logikę na zasadzie takich klocuszków, które sobie ustawiasz. Nie musisz nic kodować. Tworzysz sobie endpointy w ten sposób. W zasadzie dostajesz gotowy backend, do którego nie musiałeś napisać ani jednej linijki kodu. Ale ten projekt upadł.

Wojtek: No tak, w każdym razie wiem, że właśnie tych rozwiązań typu Super Base ostatnio mega dużo się zrobiło. Next zaimplementował niejako swoją część, czyli właśnie Database as a Service opcje w postaci PostgreSQL i tego KV, która nie zapewniają, czyli Key Value Storage.

Mateusz: No właśnie to jest to. My się boimy AI, mówimy, przynajmniej w niektórych środowiskach, że AI zastąpi nas. A z drugiej strony sami tworzymy nawet narzędzia bez AI, które mają zastępować naszych kolegów backendowców.

Wojtek: No tak, to rzeczywiście widać ostatnio przez to co robi Vercel, że jakoś się wyjątkowemo im się nie spodobali Ci koledzy z backendu.

Mateusz: Ja ich lubię.

Wojtek: Ja też całkiem. Ale z drugiej strony skoro mogę zrobić coś sam, to szybciej.

Mateusz: No właśnie, to jest pytanie. Szybciej tak, ale czy optymalnie?

Wojtek: A tu masz rację. I to jest dobre pytanie Mateuszu. I domyślam się, że pewnie w pewnych momentach tak, ale w pewnych momentach nie. Ciężko, tak jak zauważyłeś na początku, jest być specjalistą od wszystkiego. Ale ciekawe czy dojdzie do takiego momentu, że jeszcze będziemy razem pracować - w sensie czy są takie firmy może już, czy będą niedługo, które będą pracować na takiej zasadzie, że mamy jedną bazę kodu, powiedzmy taką aplikację Nextową, piszemy sobie razem ten kod Nextowy. Ciężko rysować tą granicę, frontend - backend. I Ty jesteś odpowiedzialny za te komponenty slash routing, a ja jako a'la backend developer jestem odpowiedzialny dalej w tej samej aplikacji, w tych samych komponentach za właśnie tą część a'la backendową czyli zapewnianie Ci Server Actions w postaci SQLa i tym podobnych rzeczy.

Mateusz: Powiem Ci, że to jest dość zabawne. Dość zabawna perspektywa. Pomyślałem sobie, że jakbyśmy spojrzeli na to, że kiedyś ten frontend był traktowany po macoszemu i w zasadzie nikt się nim nie przejmował, a tam frontend to tylko CSS, html, to co to tam ma być? I najczęściej było tak, że jeżeli mieliśmy aplikacje typowo właśnie serwerowe, te tak zwane MPA, to było tak, że ten frontend był generowany przez backend i wysyłany do przodu. Jeżeli frontendowcy, jeżeli byli w ogóle jacykolwiek frontendowcy w projekcie, to oni pracowali w aplikacji backendowej i mieli tam jakiś katalog views, layout czy cokolwiek innego i robili w tej części. A tutaj się okazuje, że minęło trochę lat i klimat się odwraca. My jako frontend tworzymy główną core'ową aplikację, a jeżeli backendowcy chcą to zapraszamy - tu jest aplikacja frontendowa możecie sobie wejść. I tutaj macie jeden katalog i tym się bawcie.

Wojtek: Ciekawe. Ciekawa wizja tego, jak to będzie wyglądać w przyszłości. Chociaż dziś już poniekąd trochę tego doświadczyliśmy. Co prawda myślę, że ciężko tutaj rysować to połączenie, ale czy w PHP nie było czegoś takiego? Jakby nie wyglądało to tak samo.

Mateusz: Wyglądało. Tylko, że mówię od strony backendowej. Od strony backendowej frontend tam wchodził o tutaj - sobie coś tam dopiszemy.

Wojtek: Jakieś jQuery dodam.

Mateusz: Dokładnie, dodam jQuery i będę programistą i będę tam tworzył. To było we wszystkich frameworkach. To backend narzucał to jak będzie frontend będzie generowany. Chociażby Magento jedynka. Zobacz - backend podjął decyzję, że struktury będą definiowane za pomocą XMLa i / lub, bo można było tak lub tak, pHTML. To był wymysł backendu, bo chciał dostarczać jakieś dane i jakieś kontrolki, które można było wstrzyknąć do komponentu, do jakiegoś fragmentu kodu, który będzie można potem wygenerować. Był jakiś schemat na przekazanie tych danych do aplikacji czysto backendowej do tych części, które były w zasadzie potrzebne na frontendzie później. Tak to działało. A dzisiaj mamy trochę odwrotną sytuację. Nawet projekt, w którym jestem, kilka miesięcy temu dostaliśmy aplikację właśnie w Next, ale to był Next ósemka, tam mieliśmy właśnie case, żeby trzeba było dodać jakieś loggery, coś do logowania danych na serwerze. Backendowy chcieli to zrobić, bo w zasadzie im na tym zależało. To w zasadzie - to my wejdziemy do tego Next i my to zrobimy już sobie sami, bo po to jest ta część backendowa. Weszli, zaczęli sobie pisać i nagle po tygodniu pisania okazało się, że ej wy tam macie backend w tym Next. Słaby, bo słaby, ale backend. To chyba w tym kierunku idzie. To był Next 8, więc już wtedy widać było, w którym kierunku Next pójdzie.

Wojtek: No i jest to po prostu dobry moment Mateuszu w takim razie, żeby być frontend developerem.

Mateusz: A mi się wydaje, że to nie jest najlepszy moment na wchodzenie na rynek.

Wojtek: To znaczy może jeszcze nie, ale myślę, że niedługo.

Mateusz: Wchodzisz na rynek, na rynek usług IT jako frontend developer, mając pewną wizję. Bardzo często jak rozmawiam z ludźmi, którzy chcą w tę branżę wejść, właśnie mają taką wizję, że frontend to są klocki, które trzeba poukładać. I to jest to, co widzi użytkownik ostatecznie. To jest półprawda. Natomiast ludzie, którzy wchodzą do tej branży, mają o wiele trudniejsze zadanie, bo muszą z jednej strony opanować cały natłok technologii, czyli ten cały chaos związany z mieszaniem właśnie frontendu i tych konceptów backendowych na frontendzie, ale też muszą wyrzucić z siebie ten pogląd, że frontend to jest malowanie i kolorowanie klocków. Bo to tak nie jest.

Wojtek: No tak, to prawda. Ale to jest zdecydowanie ciekawy kierunek. Jestem ciekawy bardzo, jak to się rozwinie dalej. Czy rzeczywiście te nasze aplikacje frontendowe będą takie właśnie frontendowe, które mają backend, niejako w sobie napisany i będziemy w taki sposób działać, czy jednak będzie inaczej. Kwestia tego oczywiście jaką aplikację developujemy. Jeśli potrzebujemy jakiejś zaawansowanej logiki backendowej, bardzo często tak jest przecież, nie chodzi nam o tylko wyciąganie danych na stronę.

Mateusz: To jest najmniejsza potrzeba, że tak powiem.

Wojtek: Czy ja wiem? Ja bym powiedział właśnie, że największa.

Mateusz: Znaczy najczęstsza, ale najprostsza. Z rzeczy, które robi backend to jest najprostsza rzecz.

Wojtek: To się zgadzam. Najczęstsza, ale najprostsza.

Mateusz: Bo backend w większości przypadków dostarcza endpointy z danymi. Pobiera dane z jakiegoś źródła i dostarcza je na frontend, a frontend te dane wyświetla. A to jest duże uproszczenie. Wiesz, możemy powiedzieć, że backend rzeczywiście ma pobrać dane. Ale w sytuacji, kiedy np. mamy do wykonania jakieś algorytmy, mamy jakiś złożone obliczenia wykonać, albo mamy obliczyć jakieś wartości, które polegają na wielu źródłach danych. To nie zawsze jest to optymalne, żeby zrobić to po stronie frontendu chociażby. Bo powiedzmy, że mamy bazę, która ma tysiące rekordów. Na podstawie tych rekordów musimy wyliczyć jakieś statystyki, wyciągnąć. Nawet miliony. Chodzi o olbrzymie ilości. I teraz okay, frontend może to zrobić, ale to będzie trwało. To będzie mieliło. To będzie w naszym jednym wątku javascriptowym, to, to potrwa nieskończoność.

Wojtek: No tak, tak, tylko że to nie tak działa. To koniec końców to nie dzieje się właśnie na frontendzie.

Mateusz: Do tego zmierzam, że frontend tego robić nie powinien. Nie musi. Bo mamy backend, Bo właśnie są narzędzia i języki, które są o wiele lepiej zoptymalizowane właśnie pod tego rodzaju operacje. I backend to nie jest tylko zwrócenie danych, to jest też często wyciągnięcie tych danych, których frontend nie powinien sam obliczać, bo byłoby to nie optymalne. Właśnie tutaj jednak bym zostawił to pole.

Wojtek: No tak, ale Mateuszu, żebyśmy się dobrze zrozumieli. Rozumiesz jak to działa. Na takiej zasadzie, że w momencie, kiedy w najnowszym Next możesz sobie w funkcji useServer czy trochę analogicznie, chociaż to też nie to samo, ten routing API w poprzednich wersjach Next - działał na takiej zasadzie, że to wszystko działo się na serwerze.

Mateusz: Tak, wiem, tam jest Node odpalony, który po prostu tam jest po prostu. Zgadzam się. Ja to wiem. Tylko, że po prostu mówię, że JavaScript nie jest językiem do wszystkiego.

Wojtek: Zdecydowanie do 90% rzeczy, a nie do wszystkiego.

Mateusz: Może być do 90, albo dokładnie do 88.

Wojtek: Nie no żartuję oczywiście. Myślę, że bardzo ciężko nie mieć klapek na oczy. Jednak w momencie, kiedy pracujemy z tymi technologiami na co dzień, przez tak długi czas, jak już z nimi pracujemy, to trochę zamyka się oczy na te pozostałe rzeczy, które dzieją się dookoła. Ponownie ciężko jest być specjalistą od wszystkiego. Poza tym chociażby sam silnik V8 czy też sam NodeJS to musi być w czymś napisany co nie jest Javascriptem, prawda?

Mateusz: Poza tym my też jako frontend developerzy bardzo często czerpiemy z konceptów, które nie powstały typowo dla frontendu, chociażby z architektur różnego rodzaju, jak MVVM. Model-View-ViewModel to nie jest koncept architektoniczny, który jest typowo stworzony pod aplikacje Frontendowe. On został wymyślony przez Microsoft chyba z tego co kojarzę pod aplikacje pisane w .NET. Podobnie Flux. Flux nie bazuje na jakimś nowym odkryciu, tylko bazuje na koncepcjach, które wyciągnął z CQRSa.

Wojtek: Zdecydowanie.

Mateusz: Gdyby nie inne technologie to my byśmy też tak trochę stali.

Wojtek: Zdecydowanie to wszystko na siebie wpływa. To nie jest tak, że możemy sobie teraz stwierdzić: dobra JavaScript wygraliśmy, to jest nasz finalny język i mam każdy problem rozwiązany. Zdecydowanie nie. Chociaż zdecydowanie podoba mi się to, jak w ostatnim czasie JavaScript i te wszystkie frameworki, które są z tym związane tak jak NextJS się rozwijają.

Mateusz: Dobrze Wojtku, więc myślę, że możemy tym pięknym, Twoim ostatnim zdaniem zakończyć nasz dzisiejszy odcinek. Wyszło wydaje mi się fajne podsumowanie tego, czym jest Next. Dlaczego jest tak popularny? Dużo na ten temat rzeczywiście padło. Osobiście zachęcamy do poznawania tego i śledzenia tego, jak ten frontend będzie się dalej zmieniał, bo według nas jest to naprawdę ciekawy kierunek. Tymczasem ślicznie dziękujemy za wysłuchanie piątego odcinka naszego podcastu Piwnica IT. Zapraszamy do subskrybowania, dzielenia się naszym odcinkiem z innymi i komentarzy. Jeżeli macie pytania piszcie do nas. Chętnie odpowiemy na wszystkie pytania. Jeżeli macie jakieś pomysły na nowe odcinki, coś jest, o czym chcielibyście, żebyśmy porozmawiali, to oczywiście zachęcamy do kontaktu. Dziękujemy ślicznie.