Marcin: Artur, na początek proszę o przedstawienie się i dwa zdania o sobie
Artur: Jestem Senior Software Developer, trochę architekt. Od kilku lat programujący w Node.js/TypeScript. W ITMAGINATION pracuję prawie dwa lata.
Zaczynałem od TurboPascala, przechodziłem przez C/C++, PHP, Javę, JavasSripta, C#, także skrypty mIRC’a, ale sporo tego było. Także prawie przez wszystkie możliwe bazy danych, chmury - pełnego tego było!
Marcin: Spotykamy się, aby porozmawiać o technologiach JavaScript zdobywających kolejne obszary daleko już wykraczające poza świat przeglądarki internetowej. Gdzie dzisiaj możemy znaleźć JavaScript?
Artur: JavaScript jako jeden z języków w przeglądarkach, jako jedyny przetrwał aż do tej pory.
Przy okazji, okazało się, iż jest to dość popularny język, a dzięki ECMA (międzynarodowe stowarzyszenie na rzecz standaryzacji oraz komunikacji), dostaliśmy Język działająca tak samo w każdym środowisku (Trzeba dodać „w końcu”, bo kto programował aplikacje webowe jeszcze kilka lat temu pamięta jakie kombinacje były potrzebne ze względu na różnice w implementacji i działaniu skryptów na różnych przeglądarkach).
Gdy rozwiązano ten problem, okazało się, iż sam JavaScript jest bardzo wydajny. Większość testów wydajności (badane na algorytmach) wskazują na granicę 15% spadku wydajności w stosunku do tego samego algorytmu zaimplementowanego w języku C a JavaScript.
A kluczowe dla tego o czym dzisiaj rozmawiamy jest Nodejs - będący pełnym środowiskiem uruchomieniowym dla JavaScript’a bez przeglądarki, ale za to z dostępem do systemu komputera, na którym jest uruchomiony. Node’a często też wykorzystuje się do budowania aplikacji webowych do plików statycznych. Ale najważniejsze jest wykorzystanie Node.js z frameworkiem Express.js do tworzenia Back-endowych API Restowych, gRPC i innych protokołów.
Większość z Was korzystała, a na pewno widziała aplikacje pisane na środowisku łączącym Node.js z Przeglądarką, na przykład: telegram desktop, spotify desktop, discord desktop, slack desktop – i wiele wiele innych.
JavaScript’a da się też używać do pisania aplikacji mobilnych: React Native, jQuery Native czy Titanium i NativeScript. I trzeba przyznać, że działa to bardzo przyzwoicie – a przynajmniej w końcu, bo początki zarówno desktopowych jak i mobilnych frameworków były bardzo burzliwe.
Nie mogę oczywiście nie wspomnieć o zastosowaniach chmurowych, większość z was pewnie słyszała chociażby o Lambdach czy LightSail (AWS owe usługi serverless), one natywnie obsługują Node.js/JavaScript.
Marcin: No właśnie. Doskonałym przykładem popularności JavaScript jest jego zastosowanie w technologiach serverless. Szacuje się, że 52% wszystkich wdrożonych AWS Lambda zostało napisanych w Node.js. Dopiero drugi jest python, trzecia Java lubiana przed duże korpo, a czwarty C#.
Artur: Powodem tego jest prędkość JavaScriptu, oraz tego że V8 (silnik JavaScriptu pisany przez Google) jest bardzo ale to bardzo zaawansowany technicznie i ma niesamowity wprost kompilator, a dzięki technologii JIT (just in compilation) potrafi zoptymalizować kod maszynowy tego co (tutaj uwaga: dobrze napiszemy w javascripcie) tak, by jeszcze bardziej przyśpieszyć kod wykonywany.
Dodatkowym atutem jest to, iż V8, obecna w Node.js, posiada nie jeden a kilka kompilatorów. I na początku uruchamia najbardziej prosty ale jednocześnie najszybszy z nich – to dzięki niemu tak zwany ,,cold start time’’ jest jednym z najniższych w przypadku JavaScripta, ale nawet i ten czas można przyśpieszyć (trochę jak to było robione w PHP) czyli poprzez przekompilowanie kodu do postaci OpCodów/ByteCodów co jeszcze przyśpiesza ładowanie aplikacji, gdyż omijamy także i ten pierwszy kompilator.
Wspomnę jeszcze o prawdopodobnym powodzie takiej popularności JavaScript’a, ale widzianej bardziej przez pracodawcę niż deweloperów. Mianowicie - mając tak zwane fronty w JavaScriptie (no bo przecież w tym się je pisze, chociażby Angular, React, Vue) oraz mając backendy też pisane w tym samym języku - łatwiej znaleźć pracowników, którzy będą mogli pisać takowe aplikacje.
Marcin: Jesteś aniołem stróżem programu w ITMAGINATION który ma pomóc programistom Angular i React stać się deweloperami Full-Stack. Opowiedz proszę jak nam szło i jakie są największe wyzwania przed programistami Front-end wkraczającymi do świata Backend.
Artur: Zaczęliśmy od podstaw, od tego jak uruchomić własny program w Node.js, jak stworzyć projekt, co to są i jak zainstalować moduły. Jakie moduły są wbudowane (dostarczone) z Node.js’em. Gdy już to poznaliśmy, przyszedł czas na napisanie prostego backendu.
Backend ten, przez cały czas szkolenia miał swój core funkcjonalności które musiały być dostępne i zawsze były wykonywane w tej kolejności (agile - każdy krok coś rozwijał w projekcie):
Trzy razy pisaliśmy ten projekt. Zaczęliśmy od pisania go w czystym Express.js (server www dla Node.js’a). A wszystkie dane trzymaliśmy w plikach - mało wydajny system, ale pokazaliśmy najpierw samo wykorzystanie JavaScriptu do takich celów, oraz użyliśmy kilku wbudowanych bibliotek (dostęp do dysków i plików oraz hashe)
Za drugim podejściem wykorzystaliśmy moduł `mysql2` i przenieśliśmy metadane (informacje o wielkości pliku, dacie dodania pliku, haśle do pliku etc.) do tabelki w bazie danych, ale same pliki pozostały na dysku. I jak poprzednio - chłopaki zaimplementowali nasz serwis po kolei – a mając poprzedni projekt dodatkowo widzieli jak się to różni.
Gdy poradzili sobie z Bazą danych (na razie sama interakcja z nią, na tym etapie korzystali z gotowej bazy przygotowanej przeze mnie i dostępnej z Dockera), podnieśliśmy poprzeczkę - nie dość że dodając Nest.js’a to jeszcze przechodząc na TypeScripta (TS zdecydowanie zalecam przy większych projektach nad którymi pracuje więcej niż jedna osoba).
I tutaj, wszystko czego do tej pory się nauczyli i zrobili, musieli jeszcze raz napisać- tym razem korzystając z gotowego rozwiązania (wzorowanego na angularze), ORMie (bibliotece do mapowania obiektowo-relacyjnego) do bazy danych (Sequelize) oraz TypeScripcie który wymuszał na nich zachowywanie typów - przynajmniej w edytorze.
Skończony projekt (do którego dało się dostać tylko przez udostępnienie api i testować przez PostMana był końcem tego kilkudniowego kursu. Dwa dni później, zaczęli wspólnie pisać komercyjny projekt gdzie utrwalali swoje wiadomości i rozwijali je dalej. Bardzo możliwe, że już niedługo zobaczycie ich dzieło - i pamiętajcie, żadne z nich nigdy wcześniej nawet nie widział kodu pisanego na backendzie (w dowolnym języku) a jedyne co to go używał poprzez API.
Podsumowując można powiedzieć o tym, że zaimplementowali trzy razy to samo, za każdym razem podnosząc poprzeczkę.
Link do GitHub: https://github.com/itmaginationdemos/Trainings
Marcin: Od czego zatem zacząć swoją przygodę. Node, Nest.js, JavaScript czy Typescript? Jakie jeszcze inne biblioteki warto poznać żeby szybciej rozpocząć pracę?
Artur: Na początek dobrze poznać sam język JavaScript, jego struktury (pętle, instrukcje warunkowe – podstawy języka). Potem – zależy co się chce robić, ale dobrze by było poznać podstawy TypeScripta – i mówię podstawy – TypeScript ma dużo opcji i dużo oferuje, ale na początku wystarczą podstawy jak typy i interfejsy.
Gdy już to poznamy, możemy zwrócić wzrok na Node.js (czyli środowisko uruchomieniowe dla JavaScriptu bez przeglądarki) i tam stawiamy sobie pierwsze kroki – poznajemy jak to działa, kiedy się wyłącza.
Gdy już się trochę pobawimy, mamy do wyboru frameworki. Z takich znanych to
Każde z nich oferuje coś innego i, mimo że każde służy do podobnych rzeczy, to inaczej je obsługuje. Jeżeli zdecydowaliśmy się na projekt backendowy to nie obejdziemy się bez jakiejś bazy danych a najlepiej jakiegoś ORMa do jej obsługi. Najbardziej znane to Sequelize i TypeORM (ja preferuję ten pierwszy).
Jeżeli fronty – to lepiej zacząć od na przykład Vue i szablonu typu Boilerplate, czyli projektu startowego, w którym podstawowe opcje, ustawienia i inne elementy są już za nas przygotowane. Bez tego jest trudno i czasochłonnie.
Marcin: Dziękuję za rozmowę Artur.
Artur: Nie ma sprawy. Dziękuje za możliwość bycia tutaj z Wami. Jakbyście mieli pytania, to po prostu piszcie. Hej!