Чаму React павяліў у фронтэндзе, а бэкэнд застаўся поліглотным.

React абсалютна паводзяе на фронтэндзе. Бэкэнд ніколі не змогаў запрацаваць на такім жа высокім рэвэле, і тыя, хто пераходзіць з курсаў на MERN-stack у компанію з рэальным трафікам, быстра гэта заўважаюць.

Буткампы часта продаюць Mongo, Express, React і Node як аб’еднаную сістэму: адна мова для всей стак-структуры, і стварэнне аплікацыяў у стылі full-stack стае доступным. Падпроекты і маленькія розмішчэння CRUD-аплікацыяў, здаецца, падтверджаюць гэта. Але першая работа ў компаніі з мільйонамі корыстнікаў паказвае іншую картыну. UI, як і чакалася, адбудованы на React. Основныя сервісы — на Java, мікросервісы з высокай працэздатнасцю — на Go, а праграмы машыннага навчання — на Python. Node.js выкорыстоўваецца пераважна як тонкі шар, які агрэгуе API-і для фронтэнду. У масштабных сістэмах ён выступае як падтрымкі для моцных бэкэндзаў, і прычыны гэтага ёсць конкрэтныя.

Першая прычына: адна ніт, многа задач

Node.js выконвае JavaScript на адзінай ніткі. Ён чырплёва справляецца з задачамі вводу/выходу, але за раз можа выконваць толькі адну задачу, якая сільна захопляе CPU. Уявіце рэсторан з аднім абсалютна шырокім парабаром: прыём замовленняў, што адпавядае праце з базамі дадзенаў і сеткамі, не стварае проблем. Але калі кліент замовляе п’яціблюдны стол, на падготавку якога трэба 30 хвілін — што адпавядае працы CPU — той парабар застоіцца, і всі іншы будуць чакаць.

Платформа для відэа паказвае, што гэта значыць у практычных умовах. Карыстальнік заваносі файл 4K, і сервер павінен:

1. Прыняць файл.
2. Перэкодаваць яго на кілька размаў, напрыклад 1080p, 720p і 480p.
3. Стварыць мініяцюры.
4. Выявіць метаданы.
5. Зберагчы выходныя даны на правых месцах.

Выкананне всіх гэтых задач унутрь працэсу Node блакуе яго цыкл адбытка званоцей. Іншыя завантажэнні чакаюць, іншыя запыты API стаюць у чэргу, і прыкладнэе перастае рэагаваць. Java і Go выкарыстоўваюць калькольванні, таму адна з іх можа апрацоўваць відэа, пакалі іншыя обслугоўваюць трафік API і аўтэнтыфікацыю. Node чырпаець для задач, якія залежаць ад I/O, такіх як API, чат у рэальны час і стрымінг дадзэнняў. Задачы, якія залежаць ад CPU, являюцца яго слабым месцам, а большыя прыкладнэе часта маюць ў сабе багато такіх задач.

Другія прычына: мікросервісы дазваляюць кожнай камандзе выбіраць

Большыя компаніі пераважна перасталі ствараць моноліты. Моноліт аб’еднвае аўтэнтыфікацыю, платэжы, прыемы паведамленняў і рэкамендаціі ў аднай базе коду. Архітэктура мікросервісаў дзеліць іх на незалежныя сервісы, якія вярбуюцца праз сетка.

Такое раздзеленне дазволяе кожнай командзе выбраць сабе мову. Команда, якая займаецца платэжамі, можа выбраць Java, адколькі яна падтвердзілася ў фінансавых транзакціях. Команда для чату у рэальны час можа выбраць Go за ўмэнне падтрымваць тыясячы одночасных з’яўленняў. Команда, якая стварае рэкамендаціі, можа выбраць Python за ўмэнне яго бібліятэкаў машыннага навчання. Node стае аднай з вароўсцей сярод іншых і рэдка ўжо ўсталяваецца як стандарт.

Чаму Go і Java домінуюць

Go быў створаны ў Google з мэтай выправлення проблем ранейшых мов. Яго прынтэсы:

• Канкурэнцыя. Гарутыны можа падтрымваць вельмі вялікія колькасці одночасных з’яўленняў за дапамогою мінімальнай колькасці памяці.
• Запуск. Програмы кампілююцца у натыўны машынны код і запускаюцца практычна мгновенна.
• Размешчэнне. Для розповсюджэння достатнек адной бінарнай файловай структуры без додатковых залежнасцяў пад час выканання.

Uber выкарыстоўвае яго для дзеякіх з сваіх найбольш актыўных сервісаў, Twitch — для чату у рэальны час, а Dropbox адзвярнуў значныя павышэнні карыстоўнасці пасля таго, як частыну сваей інфраструктуры перанесла з Python.

Java ўжо больш чым 25 гадоў ёсць стандартам для корпаратыўных праектаў. Ён можа здавацца застарэлым, але ёсць надзеяным:

• Ён апробаваны ў банкавасці, авіакомпаніях і велікіх інтэрнэт-магазінах.
• Яго экасістэма включае Spring Boot, Hibernate і тыячы бібліятэкаў.
• Статычны тыпаванне дапамагае выявіць многія бяды ў момент компілявання, яшчэ перш чым продукт будзе выкорыстоўваны.
• Інструменты для аналізу, манітарынгу і адлагоджэння працуюць усё гэты час і ўдосконаляюцца.

Netflix, Amazon і Airbnb выкарыстоўваюць яго для ключоўых частак сваей бэкенд-інфраструктуры. Гэтыя організацыі патрабуюць надзеянасці у вельмі вялікіх масштабах і не стараюцца следаваць трэндам.

Трэція прычына: спадчына і інерцыя

Большы компаніі маюць давню історыю. Amazon быў створаны у 1994 годзе, Netflix — у 1997 годзе, Google — у 1998 годзе. У ўсіх іх ёсць мільйоны рэядоў коду на мовах Java, C++ і Python, інфраструктура, пабудаваная пра гады, а таксама інжынеры, якія ўмелі працаваць на гэтыях мовах. Перапісваў код на Node толькі таму, што гэта модна, ня ўхідна задача. CTO большай корпорацыі не будзе рызыкаваць сістэмай платэжаў, якая безпасэродзе прыносіць дохад, на новай мове толькі таму, што яна популярная сярод распрацоўшчыкаў у Інтэрнэце.

Чаму React ўз’ект аднаковасці

Тыя ж самыя компаніі адмаўляюць React таму, што ён рашыў рэальную проблему. Да яго появы стварэнне складных інтэрфейсоў было складным: заплутаны jQuery, незрозумелыя патэрны Backbone, цыкл апрацоўкі дадзеных у Angular 1.x. React прынёс архітэктуру компонентав, віртуальны DOM для паўшчыні, дэкларатыўны інтэрфейс і вялічзеную екосыстэму, якая включае Next.js і React Native. Ён павярнуўся таму, што быў лепшы за іншыя альтэрнатывы.

У Node.js няма эквівалентнага неабяжлівага моманту на серверэ. Бн хорашы і ўзлежны выбар для пэўных задач, але для большасці серьёзных задач на бэкэндзе ён не ўсё такі лепшы за Java, Go чы Python, таму ён не ўсё такі абавязковы выбар.

Як структуруецца большая аплікацыя

Тыповыя дыяграмы паказваюць, як фронтэнд на базе React выклікае API-шлюз, а рутэр направляе кожны запіт да правага бэкэнд-сервіса. За ім:

• Бэкэнд на базе Node.js для фронтэнда карацецца логікай, спецыфічной для фронтэнда, агрэгацыяй API і рэальнага часу. Сюды саме Node.js паслужае найкрашча.
• Сервісы на базе Java адпавядаюць за платэжы, замовленні, аўтэнтыфікацыю корыстнікаў і утрыманне інвентару — тыя часткі, якія не можаць зламацца.
• Сервісы на базе Go адпавядаюць за чат у рэальны час, стрымінг і ўсё, што трэбуе вялікай канкурэнціі.
• Сервісы на базе Python адпавядаюць за рэкамендаціі, апрацоўку зображэнняў і аналітыку.

Кожны сервіс мае своі базы дадзеных, і сервісы выкананыя ўзаемнае спілкуванне праз gRPC, WebSockets або очэквальнія ляйніі паведамленняя, такія як Kafka. У частцы фронтэнду ёсць адны явны выграўшык. У частцы бэкэнду вікорыстоўваюцца разныя мовы, і выбіраецца той інструмент, які падходзіць для задачы.

Короткае паўстанавленне мов

• Node.js падходзіць для стартапаў, MVP-распрацоўак і шароў BFF. Развіцце ў яго ўмоўна, экасістэма npm вельмі вялікая, а распрацоўшчыкаў JavaScript ёсць паўсюды. Ён не падходзіць для апрацоўкі відэа аб фінансавых транзакцый.
• Java — надзеяны інструмент для працы. Ёго выучэнне ўмоўна, а запуск — медленны, але яго трэба выбіраць, калі немагчыма дапусціць абыякавасць у 3 гадзіны ночы ў Дзень чорнага пятніцы.
• Go — гэта тое, як могла бы выглядаць мова для бэкэнду, якбы яе спроекавалі занова сёння: быстрая, простая і здатная да паралельнай працы. Яго недзея — меньша экасістэма, чым у Java.
• Python ўладае сферай наукы пра даныя і машыннага навчання. Аднак для API з высокай паралельнасцю Global Interpreter Lock становіць справжню перакосу.
• C++ падходзіць для сітуацый, якія трэбуюць максімальной швальнасці, такіх як ігровыя двыжкі, вбудованыя сістэмы і торгавля на высокіх частотах. Ён не прызначаны для веб-API.

Што гэта значыць для моладых распрацоўшчыкаў

Нічыга з гэтага не робіць Node паслабленым. Ён застаецца чыраклівым выборам для стартапаў і MVP, дзе важліва швальнасць выходу на рынак, для слоёў backend-для frontend, для функцыяй у рэальным часе, такіх як чат і жывыя апдэты, для безсерверных функцый на AWS Lambda або Vercel Edge, а таксама для пратотыпаў, якія прагледваюць ідэі прычымоўваючыся да болей складных рашэнняў.

Кожны, хто прагне працаваць у вялікай кампаніі, не должны пакладацца толькі на MERN. Болей корыстным ўзвычай ёсць выучыць, як працуюць сістэмы, ўпэўніўшыся такім чынам у можлівасці выбраць правы інструмент для кожнай задачы. Неправільны падход — думка, што ведаўце JavaScript значыць можна робіць все.

Найсільнейшыя распрацоўшчыкі не прыкрэпляюцца да аднаго языка. Адна людзь можа пісаць JavaScript для інтэрфейсу, аднойчы выкарыстоўваць Java-сервіс пад час яго аналізу, зрозумець, чаму каманда выбрала Go для мікросервіса, і адразу ж адгукнуцца, калі Python будзе лепшым выборам. Яны ўмеюць вікорыстоўваць разныя языкі, бо розумеюць, што разныя проблемы выклікаюць разныя рашэнні, а не таму, што хочуць пахваліцца.

Правы інструмент для кожнай задачы

React выграў у сферы інтэрфейсаў, і кожная вядомая компанія выкарыстоўвае яго з важлівых прычын. Бэкенд лепей апісваць як экасістэму, чым як аблокаванне. Java, Go, Python, C++, Rust і Node — усе яны маюць сваё месца, і компаніі, якія ствараюць повсякдзенныя дапыткі, не прымушваюць выкарыстоўваць толькі адну мову.

Мета распрацоўшчыка — рашаць проблемы, а не выкарыстоўваць тую мову, якая ўжо знаёмая, і інодзе гэта значыць трэба выучыць што-нова. Молады распрацоўшчык, які мае сертыфікат MERN, не павінен панікаваць. Node — гарная пачатковая пунктазія. Продавайце далей: паглядзіце на праект Java Spring Boot, напісце маленькі мікросервіс на Go і дазнаецеся, чаму паявная служба компаніі напісана на Java, а не на JavaScript. Найлепшыя інжынеры — тыя, якія знаюць не больш заўсёды мов, а тыя, якія разумеюць, чаму кожная з іх існуе і калі яе трэба выкарыстоўваць.

Спадневаная літэратура

• Установка фронтэнда на React з дапамогайю Node, npm і Vite — Адаптаванне інструментаў у стылі Python да стака React плюс Vite: установка Node, ігнораванне папкі node_modules, стварэнне структуры з дапамогай Vite і запуск локальнага сервера разработкі.
• Адказа на CRUD: дзесяць архітэктурных прыемаў, якія дапамагаюць падтрымваць працэснасць аплікацыяў MERN — З’ясавайце прыемы на рэвэле сістэмы, якія дапамагаюць падтрымваць аплікацыю MERN у здароўым стане па меры ўзросту: адпаведальнасць за даны, кантракты API, выведзены стан, шаравая структура коду, лёгкія пакеты дадзеных і адносныя памылкі.

Скількіх запітоў насамрэч можа апрацуе сервер Node.js? — Тэсты на навантажэння API на базе Express на Heroku і AWS у параўнанні з Django, оцэнка працэздатнасці у 40 тыс. запытоў на секунду, а таксама фактары, якія спамляюць працу рэальных API.