Szukasz najlepszych programistów Java? Znajdziesz ich w kilka kliknięć.

Budowanie mikroserwisów JavaScript z Node.js

12 sty 202213 min czytania

Dawid Karczewski

Senior full stack developer i CTO w Ideamotive.

W wytwarzaniu oprogramowania mikroserwisy to odmiana architektury zorientowanej na usługi (SOA), w której aplikacja zbudowana jest wokół zestawu połączonych ze sobą usług. W mikroserwisach architekturę aplikacji buduje się na lekkich protokołach. Usługi są w niej dobrze przemyślane. Mikroserwisy dzielą aplikację na mniejsze usługi i poprawiają jej modułowość.

 

W porównaniu ze swoją poprzedniczką, architekturą monolityczną, mikroserwisy dają więcej korzyści. Nie musisz upychać wszystkich komponentów i usług w jednym wielkim kontenerze. Dzięki mikroserwisom zbudujesz aplikację, która ma:

  • dużą elastyczność,
  • wysoką skalowalność,
  • ciągły rozwój,
  • uporządkowaną organizację danych,
  • optymalizację czasu,
  • niezawodność.

 

Budowanie aplikacji JavaScript na mikroserwisach pozwala skupić się na tworzeniu jednofunkcyjnych modułów o dobrze zdefiniowanych operacjach i precyzyjnych interfejsach. Proces wytwarzania staje się elastyczniejszy, a problemy z ciągłym testowaniem maleją.

 

Zaciekawiło Cię to? Pokażemy Ci tu również inne korzyści z mikroserwisów, wyjaśnimy, czym są mikroserwisy w Node.js, i przedstawimy przykładowe wdrożenia mikroserwisów w Node.

 

Zaczynajmy!

Dlaczego mikroserwisy razem z Node.js?

Zastanawiasz się pewnie, dlaczego akurat mikroserwisy w Node.js. Weź dowolny popularny projekt webowy, a jest spora szansa, że powstał w Node.js. Programiści chwalą to ogromnie popularne środowisko uruchomieniowe JavaScriptu za elastyczność i wydajność. To samo można zresztą powiedzieć o architekturze mikroserwisowej. 

 

Jakie korzyści dają obie te rzeczy i dlaczego w większości przypadków warto budować aplikację na mikroserwisach w Node.js, zwłaszcza w modelu SaaS?

Korzyści z mikroserwisów

Skalowalność

Utrzymanie złożonej aplikacji w dużym zespole jest sprawniejsze, gdy opiera się ona na mikroserwisach - łatwiej wtedy podzielić odpowiedzialność między programistów.

Elastyczniejszy proces wytwarzania

Budowanie aplikacji na mikroserwisach pozwala programistom skupić się na dobrze zdefiniowanych modułach, przez co tworzenie, testowanie i utrzymanie stają się elastyczniejsze i płynniejsze.

Sprawniejsze wdrażanie

W przeciwieństwie do architektury monolitycznej aktualizacja mikroserwisu nie wymaga wdrażania całej aplikacji. Wystarczy udostępnić REST-owe API dla pozostałych usług.

Lżejsze iteracje

Programiści mogą iterować nad mikroserwisami osobno, bez oglądania się na inne komponenty.

Niezależność od języka

Mikroserwisy można pisać w wielu różnych językach programowania, co daje dużą swobodę w budowie całej aplikacji.

Wady mikroserwisów

Trudno zarządzać całością

Architektura mikroserwisowa bywa mieczem obosiecznym. Z jednej strony łatwiej utrzymać małe jednostki niż jedną wielką i złożoną. Z drugiej - gdy trzeba zarządzać aplikacją jako całością, przy mikroserwisach jest to trudniejsze.

Trudne testy

Ten sam problem dotyczy testowania - wydaje się sprawniejsze testować każdy mikroserwis osobno, ale w aplikacji monolitycznej można uruchomić testy end-to-end i szybciej natknąć się na błędy.

Problemy przekrojowe

Logowanie, cache'owanie i inne kwestie dotyczące całej aplikacji łatwiej ogarnąć w architekturze monolitycznej, bo trzeba zająć się tylko jedną aplikacją.

Wiele wdrożeń

W aplikacjach monolitycznych programiści obsługują tylko jedno wdrożenie, w odróżnieniu od mikroserwisów, gdzie wdrożeń może być wiele. W części przypadków oszczędza to sporo czasu i wysiłku.

 

Ogólnie architektura monolityczna jest najlepszym wyborem dla lekkich produktów bez rozbudowanej logiki biznesowej. Mikroserwisy z kolei doskonale pasują do złożonych, rozwijających się aplikacji projektowanych z myślą o skalowaniu. Dotyczy to zwłaszcza produktów SaaS, które dziś mogą mieć 1000 użytkowników, a jutro 100 000, więc muszą być gotowe na wykładniczy wzrost - użytkownicy płacą zwykle miesięcznie i potrzebują wysokiej dostępności. To wszystko sprawia też, że programiści wolą budować swoje produkty w Node.js.

Dlaczego akurat mikroserwisy w Node.js?

Jak wspomnieliśmy, mikroserwisy są niezależne od języka programowania, co jest jedną z największych zalet tej architektury. Jednocześnie związek Node.js z mikroserwisami jest wyjątkowo silny i głęboki. Jedną z idei stojących za powstaniem tego środowiska było zresztą ułatwienie i usprawnienie budowy aplikacji opartych na mikroserwisach. 

 

Z perspektywy biznesowej wykorzystanie zalet obu technologii istotnie wpływa na produkt - nie tylko w momencie tworzenia, ale też później, przy utrzymaniu i skalowaniu. 

 

Z praktyki: pewna usługa przeszła z PHP na Node.js i stała się o 70% szybsza. Zużywała też mniej zasobów. Inny przykład: GoDaddy przeszło z .Net na Node.js i było zachwycone. Netflix skrócił czas ładowania aplikacji o 70%. Przyjrzyjmy się kolejnym powodom, by wybrać Node.js do następnego mikroserwisu:

Lepsza kontrola kosztów

Node.js i mikroserwisy są stworzone do skalowania. Zwłaszcza w produktach SaaS ważne jest nie tylko udźwignięcie wzrostu, ale też utrzymanie jak najniższych kosztów wytwarzania i utrzymania. Żadna architektura monolityczna nie da takiej elastyczności.

Lepsza wydajność i niezawodność

Powyższy argument sprawdza się też przy utrzymaniu wysokiej wydajności: jeśli jeden mikroserwis padnie przez błąd lub inny problem, cała aplikacja nie ucierpi. Znaczenie ma również to, że Node.js jest jedną z najpopularniejszych technologii webowych - łatwiejszy dostęp do specjalistów i społeczności ułatwia wyciśnięcie z aplikacji najlepszej wydajności.

Umożliwia tworzenie full-stack 

Front end zdecydowanie powinien powstać w JavaScripcie. Wybór frameworka lub biblioteki frontendowej to oczywiście osobna dyskusja. Z Node.js ten sam JavaScript wykonuje się także na serwerze. Jeśli w zespole jest 5 programistów i wszyscy piszą w JavaScripcie, znacznie łatwiej im być full-stackowcami. Owszem, muszą poznać koncepcje backendu i frontendu, ale nie muszą uczyć się zupełnie nowego języka.

Wbudowany serwer WWW dla mikroserwisów Node.js

Node.js ma wbudowany serwer WWW. Nie musisz spierać się o kolejny Nginx czy Apache. Możesz też radośnie pożegnać rzeczy takie jak FPM, bo Node.js jest zasadniczo jednowątkowy.

Jedna z najlepszych wydajności

Node.js skutecznie obniża wymagania infrastrukturalne (CPU, pamięć) potrzebne do obsłużenia tej samej liczby żądań, co ostatecznie zmniejsza koszty. Dzięki JavaScriptowi oszczędzasz czas na etapie kompilacji, bo to język interpretowany, co finalnie pomaga wydajności.

 

W Node.js moduł jest cache'owany od pierwszej instancji. Potem za każdym razem, gdy go potrzebujesz, odwołujesz się do wersji z cache'u. Ponieważ Node.js ma standardowe API strumieni, zapewnia najlepszą wydajność i bezpieczne tworzenie aplikacji czasu rzeczywistego, takich jak czaty czy gry online.

Szybka krzywa uczenia

Node.js ma szybszą i łatwiejszą krzywą uczenia niż Java czy .NET. Ponieważ Node opiera się na JavaScripcie, programiści z doświadczeniem w JS szybko go rozumieją i zaczynają pracę w ekosystemie Node.js. Osoby po C#, Javie czy Pythonie też bez trudu się go nauczą.

Szybsze wytwarzanie, wysoka wydajność i skalowalność

Node.js zmniejsza liczbę linii kodu mniej więcej 2-3 razy w porównaniu z Javą czy .NET, co poprawia utrzymywalność.

 

Ponieważ kod Node'a i frameworków UI opiera się na JavaScripcie, rośnie produktywność - znika przepaść między programistami front-endu i back-endu. Programiści nie muszą też jawnie parsować danych na poziomie UI, bo obie strony komunikują się w formacie JSON.

 

Dzięki znakomitemu nieblokującemu, zdarzeniowemu I/O do pisania nieblokującego kodu Node.js jest wyjątkowo szybki w aplikacjach o niskim zużyciu CPU, sterowanych wejściem-wyjściem (zapytania do bazy, wywołania API itd.). Świetnie współpracuje z architekturą baz NoSQL, bo i Node, i NoSQL dobrze radzą sobie z parsowaniem JSON-a.

 

Node Package Manager (NPM) daje mnóstwo gotowych pakietów, które ułatwiają pracę. Według najnowszych statystyk Google liczba dostępnych modułów NPM jest niemal dwukrotnie większa niż w Javie.

Przyjazny: łatwy w konfiguracji, integracji i utrzymaniu

Kod Node.js łatwo skonfigurować i utrzymać w porównaniu z odpowiednikami w Javie, .NET czy Pythonie. Nie wymaga skomplikowanej konfiguracji instalacji. Dzięki platformom takim jak Express, Sail i Hapi Node.js pozwala szybko tworzyć i dostosowywać API.

 

Komunikacja między mikroserwisami odbywa się głównie na dwa sposoby - przez wywołania API i brokery wiadomości. Node.js łatwo i szybko integruje się z większością nowoczesnych brokerów, takich jak RabbitMQ i Kafka. Dzięki temu świetnie nadaje się do systemów rozproszonych. Wspiera też budowę aplikacji full-stack - wewnętrznych i zewnętrznych - z użyciem silników szablonów, takich jak EJS czy Jade. Podobnie jak przy mikroserwisach idziemy dziś w stronę architektury serverless, a Node.js świetnie pasuje do Lambdy dzięki mniejszemu zużyciu pamięci i lżejszemu kodowi, co pomaga przy zimnym starcie.

Wyzwania przy używaniu Node.js do mikroserwisów

Mimo wielu zalet Node.js w tworzeniu mikroserwisów ma on kilka ograniczeń:

Ograniczona wydajność przy zadaniach obciążających CPU

Przy aplikacjach mocno obciążających procesor Node.js blokuje aplikację na czas takiego żądania i ustawia wszystkie przychodzące żądania w kolejce. Aplikacja może przez to przestać odpowiadać.

Niestabilne API Node'a

API Node'a zmienia się w kolejnych wydaniach. Czasem te zmiany nie są wstecznie zgodne. Wtedy aplikacja zbudowana w Node.js może stać się niestabilna, bo programiści muszą poprawić kod, żeby działał z najnowszymi wersjami.

Nieefektywny przy bazach relacyjnych

Node oczywiście dobrze integruje się z architekturą baz NoSQL, bo obie opierają się na strukturze JSON. Przy bazach relacyjnych okazuje się jednak nieco mniej efektywny i wydajny.

Niezweryfikowane i porzucone pakiety NPM

Liczba dostępnych pakietów NPM w Node.js jest niemal dwa razy większa niż w Javie, C# i innych. Ponieważ wiele z nich nie jest zweryfikowanych, bywają słabej jakości i dostarczają niedojrzałych narzędzi.

Kiedy używać mikroserwisów w Node.js

Wyobraź sobie, że budujesz aplikację korporacyjną, która musi spełniać następujące warunki:

  • Obsługa różnych klientów: przeglądarek desktopowych, mobilnych i natywnych aplikacji mobilnych.
  • Udostępnienie API dla podmiotów zewnętrznych.
  • Integracja z innymi aplikacjami przez usługi sieciowe lub brokera wiadomości.
  • Uruchamianie wielu instancji aplikacji na wielu maszynach, by spełnić wymagania niefunkcjonalne dotyczące skalowalności i dostępności.
  • Wdrożenie nowego stosu technologicznego.
  • W planach jest zbudowanie pipeline'u ciągłego wdrażania dla aplikacji.

 

Na podstawie powyższych wymagań można śmiało powiedzieć, że aplikacja w 100% nadaje się do architektury mikroserwisowej w Node.js.

 

Musisz zdefiniować architekturę, która ułoży aplikację jako zestaw luźno powiązanych, współpracujących usług. Usługi mogą komunikować się protokołami synchronicznymi lub asynchronicznymi. Można je rozwijać i wdrażać niezależnie od siebie. Każda ma własną bazę danych, odseparowaną od pozostałych.

 

Przyjrzyjmy się typowym scenariuszom, w których warto rozważyć architekturę mikroserwisową:

  • Migracja aplikacji monolitycznych ze względu na wymaganą poprawę skalowalności, zarządzalności, elastyczności lub tempa dostarczania.
  • Przeniesienie starszej aplikacji na nową platformę przez zamianę funkcji i modułów w mikroserwisy.
  • Przepisanie starszych aplikacji na nowoczesne języki i stos technologiczny, by odpowiadały dzisiejszym potrzebom biznesu.
  • Wydzielenie usług end-to-end, które są z natury niezależne. Na przykład usług szyfrowania czy uwierzytelniania.
  • Niezależne aplikacje lub usługi biznesowe wykorzystywane w wielu kanałach. Na przykład usługi płatnicze, logowania, wyszukiwania lotów, profilu klienta, powiadomień itd.
  • Często używane aplikacje firmowe. Na przykład aplikacja do ewidencji czasu pracy.
  • Sytuacje, w których dostawca udostępnia klientowi zasoby obliczeniowe i zarządzanie infrastrukturą według potrzeb. Na przykład usługi prognostyczne, cenowe itd.
  • Usługi backendowe dla responsywnej aplikacji frontendowej, w której dane mogą pochodzić z wielu kanałów lub różnych źródeł.
  • Bardzo elastyczne aplikacje albo takie, w których liczy się tempo dostarczania i czas wejścia na rynek, projekty pilotażowe itd.
  • Aplikacje tworzone poliglotycznie, wielojęzycznie, w modelu chmurowym.

Jak podejść do budowy mikroserwisów w JavaScripcie: role i zasoby 

W erze internetu i rozwiniętych usług outsourcingowych wciąż są tacy, którzy wierzą, że wystarczy zatrudnić jednego programistę do wszystkiego. Tacy przedsiębiorcy są przekonani, że z takim „zespołem” da się naprawdę zbudować mikroserwis.

 

Jak jednak pokazuje nasze doświadczenie, architektura mikroserwisowa daje wiele korzyści, a gdy nad wieloma usługami pracuje wielu programistów, zadania kończą się szybciej. Dzieli też całą aplikację na małe, niezależne usługi, co bardzo pomaga w rozwoju, skalowaniu, testowaniu i rozumieniu aplikacji. 

 

Zobaczmy więc, jakie role i zasoby są potrzebne:

Struktura zespołu

  • Architekt oprogramowania (SA)
  • Zespół produktowy: product owner, product managerowie i analitycy biznesowi
  • Zespół deweloperski: Scrum Master, programiści i inżynierowie QA
  • Zespół DevOps / infrastruktury
  • Administrator baz danych (DBA)

Wybierz ekspertów z potrzebnymi umiejętnościami

Umiejętności potrzebne programiście mikroserwisów na etapie projektowania

  • DDD. Żeby tworzyć mikroserwisy, programiści muszą opisać i zaprojektować model pojęciowy rozwiązujący problemy konkretnej domeny. Mogą użyć podejścia Domain-Driven Design (DDD). Opisują niezależne obszary biznesowe jako problemy przypisane do poszczególnych mikroserwisów.

Umiejętności przydatne przy rozbijaniu monolitu

  • Znowu DDD. Zalecany sposób podziału monolitu to użycie DDD, wprowadzenie dobrze zdefiniowanych kontekstów ograniczonych i wdrożenie komunikacji asynchronicznej.
  • Kolejki wiadomości. Jednym z najpopularniejszych narzędzi do asynchronicznej komunikacji w systemach rozproszonych jest Apache Kafka.
  • Event sourcing. Rozdzielenie łatwiej osiągnąć dzięki źródłom zdarzeń. To świetna alternatywa dla tradycyjnej architektury CRUD. Centralnym pojęciem jest stały strumień zdarzeń, który zarządza wszystkimi zmianami w modelu odczytu i uruchamia logikę biznesową. Świetnie pasuje to do mikroserwisów, bo oba podejścia dążą do lepszego i wydajniejszego wykorzystania dostępnych zasobów systemu.

Umiejętności przydatne przy skalowaniu mikroserwisów

  • DevOps. Żeby poprawnie skalować mikroserwisy, programiści potrzebują przynajmniej podstawowej wiedzy o DevOps. Cenne jest też doświadczenie z kontenerami Docker. DevOps to warunek udanego wdrożenia mikroserwisów.
  • Znajomość technologii chmurowych. Narzędzia DevOps pozwalają opłacalnie skalować aplikacje mikroserwisowe. Skonteneryzowane środowiska chmurowe, takie jak mikroserwisy, zmuszają firmy do szukania inżynierów z praktycznym doświadczeniem w Google Cloud Platform (GCP), Amazon Web Services (AWS) i różnych narzędziach service proxy.
  • Znajomość popularnych frameworków. Programista mikroserwisów korzysta z popularnych frameworków, takich jak Spring Boot w Javie czy Lagom - otwarty framework do budowy reaktywnych systemów mikroserwisowych w Javie lub Scali.

Umiejętności inżyniera przydatne przy wdrażaniu mikroserwisów

Każdy zespół może rozwijać, wdrażać i skalować swoją usługę niezależnie. Nie ma potrzeby rozrastania zespołu, a fragment, za który odpowiada jeden programista, jest zrozumiały i przyswajalny. Małe, autonomiczne zespoły napędzają rozwój i całego zespołu, i pojedynczych osób. Wymaga to zaufania i pewnych kompetencji miękkich, głównie tych dwóch:

  • Ciekawość. Ciekawość i podejście „ciągłej nauki” to cechy świetnych programistów. Upraszczają zrozumienie potrzeb biznesowych i przełożenie ich na funkcje oprogramowania. Co zaskakujące, zadawanie pytań - nawet tych najprostszych - to najłatwiejszy i najskuteczniejszy sposób poznania celów biznesowych.
  • Praca zespołowa. To praca zespołowa spełnia marzenia. Dobra komunikacja i gotowość do pomocy innym, a w razie potrzeby wzięcia osobistej odpowiedzialności, tworzą świetny zespół.

Narzędzia automatyzacji dla twórców mikroserwisów

Ciągła integracja

Zielone testy są świetne, ale jak to osiągnąć w projekcie? Dobry inżynier powinien umieć zaprojektować pipeline'y CI (continuous integration), żeby nowe funkcje i poprawki dało się szybko przetestować. Wdrażanie wymaga z kolei znajomości pipeline'ów CD (continuous delivery). Brzmi jak coś zwyczajnego dla dowolnej architektury oprogramowania.

Testowanie

Jakie inne testy poza end-to-end są ważne dla niezawodnych rozwiązań? Nie pomijaj testów jednostkowych ani testów usług i API, żeby jak najdokładniej sprawdzić swoje endpointy.

Kontenery

Mikroserwisy wprowadzają jednak dodatkową warstwę złożoności operacyjnej, więc ich twórcy muszą mieć praktyczne doświadczenie z narzędziami automatycznego wdrażania i orkiestracją Dockera.

 

Podsumowując: zatrudniając dedykowany zespół programistów, upewnij się, że każdy z nich ma potrzebne umiejętności i doświadczenie w pracy z powyższymi narzędziami.

Dostępność specjalistów i popularność języka

W trzecim kwartale 2020 roku, według Developer Economics, liczba programistów używających JavaScriptu wynosiła 12,4 miliona. Oznacza to, że 53% wszystkich programistów na świecie kiedykolwiek korzystało z JS.

 

Mikroserwisy to obowiązkowa umiejętność programisty JavaScript, więc raczej nie będziesz mieć problemu ze skompletowaniem zespołu. Według Stack Overflow Developer SurveyJavaScript jest technologią o najlepszych wynikach - używa go 68% profesjonalnych programistów.

 

Jeśli jednak mowa o Node, programistów Node.js nie ma tylu co programistów JavaScriptu. Rosnący popyt na Node.js pozostaje niezaspokojony, bo programistom brakuje zawodowego doświadczenia z tą stosunkowo nową technologią.

 

Zadowolenie programistów to jednak sprawa subiektywna, na którą wpływa wiele czynników. 2018 Node.js User Survey Report podaje:

„Node.js nadal wpływa pozytywnie na użytkowników, zwłaszcza jeśli chodzi o produktywność i satysfakcję programistów; poproszeni o opisanie Node.js respondenci używają głównie pozytywnych określeń, takich jak »szybki«, »lekki«, »fajny«, »potężny«, »elastyczny«, a nawet »zabawny«”.

 

Możemy więc liczyć na lepsze wyniki Node.js pod względem dostępności specjalistów.

Przykłady mikroserwisów JavaScript z Node.js z życia wzięte

Żeby zrozumieć rosnący trend, warto przyjrzeć się firmom, które korzystają z mikroserwisów w Node.js, problemom, na jakie natrafiły, i temu, jak Node.js pomógł je rozwiązać. Dlatego wybraliśmy trzy najciekawsze firmy używające Node.js i przygotowaliśmy przewodnik po ich przypadkach, żeby pokazać, dlaczego i Ty powinieneś rozważyć przejście na Node.js.

#1. Netflix - skrócenie czasu uruchamiania dzięki Node.js

Netflix stara się przyspieszyć ładowanie interfejsu, żeby poprawić doświadczenie użytkownika. Do 2015 roku korzystał z backendu w Javie, który dobrze radził sobie z zarządzaniem danymi, ale dawał użytkownikom niewielkie opóźnienia. Ponieważ frontend w JavaScripcie nie komunikował się skutecznie z backendem w Javie, Netflix zdecydował się przejść na Node.js, by skorzystać z jego wydajności.

 

Dlaczego Netflix przeszedł na Node.js:

  • Monolityczna budowa aplikacji utrudniała jej skalowanie wraz z rosnącą bazą użytkowników.
  • Przejście z backendu na frontend nie było płynne, co wydłużało czas ładowania i często powodowało opóźnienia po stronie użytkownika.
  • Dostosowanie interfejsu do potrzeb użytkownika było trudne przez synchroniczne ładowanie.
  • Uciążliwy czas budowania w Javie spowalniał tempo rozwoju i wdrażania.

 

Korzyści z Node.js dla Netflixa

  • Istotne skrócenie czasu uruchamiania o 70%. Interfejs Netflixa, który wcześniej ładował się 5-10 sekund, dziś potrzebuje niewiele ponad sekundę.
  • 40-minutowy czas startu w Javie skrócony do 1 minuty dzięki Node.js.
  • Aplikacja stała się zorientowana na mikroserwisy, dzięki czemu łatwo podzielić interfejs na mniejsze fragmenty zamiast jednego wielkiego bloku.
  • Ponieważ Node to również JavaScript, przejście z backendu na frontend znacznie się poprawiło.

„Node okazał się tak poręczny, że firma rozszerza jego użycie na kolejne warstwy stosu” - powiedziała Kim Trott, dyrektorka inżynierii interfejsu użytkownika w Netfliksie.

#2. NASA - szybszy dostęp do baz danych dzięki Node.js.

NASA, pionier aeronautyki, miała trudność ze scaleniem rozproszonych, starych baz danych dotyczących skafandrów EVA. Utrudniało to naukowcom dostęp do danych na potrzeby badań. Dostęp był wolny i wymagał grzebania w kilku miejscach, żeby zebrać dane do rzetelnych badań.

 

Collin Estes, który zaprojektował architekturę korporacyjną Node.js dla NASA, tłumaczy, dlaczego system potrzebował architektury opartej na API. Pytając, które firmy używają Node.js, nie spodziewasz się NASA - a jednak, z następujących powodów.

 

Dlaczego NASA przeszła na Node.js:

  • Dane rejestrowane przez skafandry były rozproszone w różnych miejscach.
  • Duża część danych z misji kosmicznych NASA leży w zamkniętych bazach, trudnych do odpytywania i sortowania.
  • NASA korzystała z lokalnych centrów danych, które nie były gotowe na chmurę.
  • Wiele istniejących aplikacji NASA zależało od JavaScriptu.

 

Korzyści z Node.js dla NASA (przeprowadzili kilka kluczowych zmian w zakresie gotowości na chmurę i przenoszalności danych):

  • Czas dostępu do bazy danych skrócony o 300%, dzięki czemu użytkownicy dostają potrzebne zbiory danych w sekundy zamiast w godziny.
  • Architektura mikroserwisowa Node.js pozwoliła przenieść stare bazy danych do chmury i udostępnić je użytkownikom przez API.
  • Dawny 28-etapowy proces odczytu bazy danych skrócono w Node.js do 7 kroków. Badania naukowe idą dużo łatwiej i szybciej.
  • Płynne połączenie starych baz Oracle i SQL Server z nowymi bazami w chmurze dzięki modułom data API.

 

Synchronizacja danych, możliwa dzięki Node.js, pomaga wszystkim - od astronautów po obsługę naziemną - szybko i bezpiecznie sięgać po ogromne bazy NASA.

#3. LinkedIn - lepsza wydajność aplikacji dzięki Node.js

LinkedIn, największa na świecie sieć zawodowa, ma ponad 774 miliony użytkowników. To także jedna z największych aplikacji wdrażających Node.js na produkcji.

 

LinkedIn długo działał na Ruby on Rails, zanim przeszedł na Node.js. Chcesz wiedzieć, dlaczego zapadła taka decyzja? Sprawdź ten tekst - Ruby on Rails vs JavaScript.

 

W skrócie: decyzja wynikała przede wszystkim z chęci poprawy wydajności aplikacji i zmniejszenia zużycia zasobów. Używając Node.js na backendzie, przeszli z synchronicznego na asynchroniczne przetwarzanie żądań, co dało znacznie szybsze ładowanie frontendu.

 

Dlaczego LinkedIn przeszedł na Node.js:

  • Serwer brał na siebie zbyt duże obciążenie przy każdym wzroście ruchu.
  • LinkedIn nie radził sobie z wieloma równoczesnymi żądaniami w implementacji w Ruby.
  • Aplikacja w Ruby działała synchronicznie, co utrudniało ładowanie stron.

 

Korzyści z Node.js dla LinkedIna (aplikacja w Node.js pomogła zmniejszyć zużycie zasobów i poprawić wydajność):

  • LinkedIn zdołał zmniejszyć liczbę maszyn hostujących aplikację w stosunku 10:1.
  • Zarówno klient, jak i serwer działały w JavaScripcie, dzięki czemu zespołom łatwiej było współpracować z serwerami klienckimi.
  • Kod uproszczono na całej linii, dzięki czemu stał się bardziej modułowy i mniej zależny od stanu.

„Node.js pozwolił nam też przejść na model, w którym klient wykonuje jedno żądanie na stronę. Kod się uprościł, a my przeszliśmy na serwery bezstanowe” powiedział Deepank Gupta - Senior Software Engineer w LinkedIn na blogu Medium.

Podsumowanie

Mimo drobnych mankamentów Node.js wciąż uchodzi za dobry framework do budowy realnych aplikacji JavaScript i mikroserwisów. Podstawowy rozproszony system mikroserwisowy z Node.js pokazuje, jak pojedyncze aplikacje budują komunikację między usługami. RESTowe API przetwarzają dane i wspierają kod wdrażający każdy mikroserwis.

 

W najbliższych latach Node.js będzie aktywnie używany do tworzenia dojrzałych narzędzi open source i budowy mikroserwisów dla oprogramowania klasy enterprise. Ideamotive zaś zawsze pomoże Ci zebrać i poprowadzić dedykowany zespół do budowy mikroserwisów.

 

Nasi eksperci Node.js chętnie omówią z Tobą najlepszy framework mikroserwisowy dla Node.js (Koa jest tu zdecydowanie najlepszy), wyjaśnią różnice między Pythonem a Node.jsi pokażą swoje najnowsze case study.

 

Niezależnie od wybranej drogi nasz marketplace talentów jest zawsze gotów uzupełnić Twój zespół specjalistami takich profili:


Możesz być pewien: rekrutacja z rozległą Talent Network Ideamotive to Twój najlepszy wybór!

Dawid Karczewski

Dawid jest full stack developerem. Tworzy aplikacje w Ruby on Rails i React Native od pierwszego pomysłu aż po wdrożenie. Buduje dla naszych klientów rozwiązania, które pomagają im rosnąć.

Zobacz wszystkie wpisy autora
im_ebook_cover_template 3

JavaScript: kompletny przewodnik dla przedsiębiorców i product ownerów

Wszystko, co trzeba wiedzieć o wdrażaniu JS w biznesie w 2022 roku

Czytaj teraz
Nodejs Pillar big cover

Biznesowy przewodnik po Node.js

Wszystko, co musisz wiedzieć jako product owner i CxO

Czytaj teraz