Как работает на низком уровне Node.js и Angular?

Question

[ewb]

Всем привет.
Я учился программить под веб в середине нулевых, и жестко привык к тому, что существуют всегда отдельные сущности:
1) Веб-сервер (Apache, nginx)
2) Какой-то язык обработчик на сервере (php, python)
3) Стек для верстки и динамики на стороне клиента (js, css, html)
4) Сервер базы данных

Веб сервер принимает запросы, серверный язык работает с данными и формирует html, а js и css на стороне клиента делают дизайн и какую-то динамику, ну в крайнем случае подтягиваются новые или обновленные данные через ajax.

Но вот к сожалению я плохо понимаю, как работаю современные технологии, взять тот же node.js, там уже встроен веб-сервер? Соединение с клиентом держится постоянно?
А что с Angular? Это не просто какая-то подключаемая на стороне клиента библиотека вроде jquery?
Меня интересует какая-то низкоуровневая реализация всего этого.

Comments

[Толстый Лорри]

и жестко привык к тому, что существуют всегда отдельные сущности

С технической точки зрения почти ничего не изменилось. Клиентские сценарии стали больше, API браузеров расширился, появились веб-сокеты и WebGL. Более того, с тех пор у нас пропали по-настоящему "жирные" клиентские технологии: Java Applets, Silverlight, Flash.

node.js, там уже встроен веб-сервер?

Да, сейчас мода на self-hosted-приложения, хотя перед торчащими наружу принято ставить прокси, вроде того же nginx.

Соединение с клиентом держится постоянно?

keepalive есть с HTTP1.1 (1997 год). Ajax сейчас используется чаще.

А что с Angular? Это не просто какая-то подключаемая на стороне клиента библиотека вроде jquery?

Просто фреймворк.

[ewb]

Толстый Лорри, спасибо за ответ! Если не сложно, то объясните пожалуйста некие моменты:

1)

Да, сейчас мода на self-hosted-приложения, хотя перед торчащими наружу принято ставить прокси, вроде того же nginx.

Какова производительность встроенного веб-сервера в node.js?
С какой целью ставится прокси? Безопасность? Оптимизация нагрузки?

2)

Просто фреймворк.

Который подключается, как внешняя .js библиотека на стороне клиента (вроде того же jquery) или которая подключается как-то на сервере через npm?
Если это клиентский фреймворк, то почему он подключается на стороне сервера? Или это просто для удобства и подключить можно иначе?

[Толстый Лорри]

ewb,

Какова производительность встроенного веб-сервера в node.js?

Куча тестов в интернете. Но работает он в асинхронном режиме, что счастье и боль одновременно. Короткие запросы обрабатывает быстро. Потом начинаются пляски с бубном вокруг расширения-методом-запуска-инстансов и какие-то внешние приложения-процессоры.

С какой целью ставится прокси?

Чтобы хотя бы статику отдавать средствами прокси, кэш работал. Все это не загружая работой само приложение на NodeJS. Ну и безопасность, само собой.

*Angular* Который подключается, как внешняя .js библиотека на стороне клиента (вроде того же jquery) или которая подключается как-то на сервере через npm?

Чисто фронтовая тема.

Angular, React, Knockout, Ember, ExtJS и еще куча всякого - это попытки красиво подружить HTML, CSS и JS. Грубо говоря, чтобы изменения полей вью-модели тут же изменяли представление, которое видит пользователь. Желательно - в двустороннем порядке. То есть нормальный MVC/MVVM на фронте исходя из условия, что страницу пользователь почти никогда перезагружать не должен, всё только через ajax.

nodejs и npm здесь используются как билд-система (как Maven для Java, MSBuild (+NuGet) для C#, make для C/C++, Composer для PHP) для кучи статических ресурсов (html-css-js-картиночки-шрифты и т.п.) для управления зависимостями, трансляции какого-нибудь нормального языка (например TypeScript) в мерзкий старый, но любимый браузерами JavaScript, стилей из умного (например Less) языка в тупой CSS, склеивания этого добра в единые файлы (бандлы, чтобы загружалось быстрее) и прочие операции, которые на выходе дают готовый к употреблению статический фронтенд-контент (который потом сможет быстро выплюнуть ngnix). Желательно, чтобы это происходило на лету (при сохранении файлов, нужнающихся в постобработке).
Этот фронт можно легко прикрутить к другому бэкенду, хоть на PHP, хоть на Java или C#, ибо HTTP еще никто не отменял, он еще долго будет абстракцией фронта от бэка.

Но совсем другой мир - это серверные приложения на NodeJS. По заявлениям евангелистов, с ними можно "шарить" какие-то модули между фронтом и бэкендом (ибо джаваскрипт). Однако, говорят, такой логики очень мало, а типичный фронтендщик не может на высоком уровне осилить бэкенд на NodeJS, ибо в ногу выстрелить с его единственным потоком можно легко и отвалится у тебя не один клиент, а сразу все и даже свет в доме. Сейчас хайп прошел и NodeJS, как бэкенд, перестал так волновать всех. Но в рейтингах он продолжает радовать статистикой благодаря NPM, который сейчас дефакто-стандарт во фронтенде.

[Ульян Романов]

Толстый Лорри, раунд

[ewb]

Толстый Лорри, спасибо большое! Некоторые вещи встали на свои места.

Answer 1

[ValeraValera]

думаю это Вам поможет Объясняем современный JavaScript динозавру
Как объяснить 10 лет веб-разработки путешественник...
NodeJs - это движок для JavaScript , который вынесли из браузера и добавили возможности , которые в браузерном JS были невозможны из-за безопасности , например работа с файловой системой и другие. Сам движок NODEJS называется V8 , написан на C++ и компилит JS в машинный код.

Вебсервер - это процесс который слушает определенный порт на HTTP запросы , принимает их , парсит и отдает назад ответ в зависимости от запроса. Раньше в этот ответ помещался готовый html код c данными , которые подтягивались из базы, что и было страницей.

Так как появилась возможность делать JS код вне браузера , то взяли и написали на нем веб-сервер , который все делает на JS . Что дало возможность написать и фронт и бэк сайта на одном языке

Сейчас же при запросе к серверу , сервер отдает сразу HTML код страницы с JS кодом и из этого js кода посылаются асинхронные запросы к бекенду (AJAX) на определенные url адреса сервера RESTip , которые отдают не готовые страницы , а только данные в чистом виде в формате JSON и JS парсит эти данные и вставляет в стандартные html узлы или же кастомные , которые зовутся WebComponets, но пока имеют слабую поддержку браузеров , страницы. Angular упрощает написание кастомных html узлов и внедрение в них данных плюс позволяет их реиспользовать.

Получается что у Вас может один раз прийти html + js код и потом вся работа с сайтом будет идти через одну страницу в которую javascript будет вставлять нужные данные, а при необходимости еще и обрабатывать их перед вставкой. Сайты , которые так работают называются SPA (Single Page Aplication).

Answer 2

[xfg]

У вас на сервере должен быть запущен постоянно работающий процесс, чтобы обрабатывать входящие запросы от клиентов. На PHP как правило пишут скрипты, которые не висят постоянно в памяти, а выполняются и умирают раз за разом. В таких условиях нужен посредник в виде постоянно работающего процесса. Поэтому вы используете apache, nginx, etc или пользуетесь встроенным php -S localhost:8080 mysite/index.php

В node.js можно несколько иначе. Скрипты висят в памяти. Чтобы с ними как-то взаимодействовать по сети, вы должны позаботиться об этом самостоятельно и реализовать некий протокол взаимодействия с вашей программой поверх tcp. Это может быть популярный и всем известный http протокол или что-то менее известное или даже придуманное вами.

Поскольку http протокол довольно популярен, то в node.js предоставили готовую реализацию в виде http модуля, который позволяет написать http сервер в несколько строк.

Строго говоря, вы это всё можете делать на любом языке, который умеет работать с сетью и PHP здесь не является исключением. Например вот одна из реализаций http сервера на PHP https://github.com/reactphp/http

Comments

[ewb]

Спасибо за ответ! Кое что стало понятней.

А как дела с производительностью обстоят у таких http серверов (как в node.js) в сравнении с тем же Apache?

[xfg]

Бенчмарки можно поискать в интернете если интересно. Но вообще, в связке веб-сервер + php принято на каждый запрос поднимать новую копию приложения. Конечно это очевидно должно быть медленнее, чем если один раз поднять приложение в памяти.

Ну и перед бекендами всё равно как правило ставят фронтенд-сервера на nginx. Например для отдачи статики или балансировки нагрузки по бекендам.

Просто рассматривайте вопрос с точки зрения, что всегда, когда вы пишите серверную часть приложения в виде долгоживущего процесса (демона), то всегда http сервер (правильнее сказать работа с сетью) будет являться неотъемлемой частью самого этого приложения. Иначе если приложение не работает с сетью, то вы очевидно не сможете с таким приложением взаимодействовать по сети. Вы пишите полноценное самостоятельное приложение.

На php же вы писали по-сути не приложение, а набор скриптов. Приложением там являлся сам php интерпретатор. Веб-сервер принимал запрос, находил необходимый файл со скриптом в файловой системе и отдавал его интерпретатору на исполнение. Интерпретатор выплевывал результат вывода скрипта, откуда веб-сервер забирал этот вывод, добавлял свои заголовки и отправлял клиенту (браузеру). Но большинство серверных программ пишутся конечно же не так, а в виде самостоятельных долгоживущих процессов (демонов).

[xfg]

ewb, ангуляр можете рассматривать как "расширенный html". Если вы хотите линию, вы пишите тег <hr>. Наверное было бы здорово, если бы вы могли таким декларативным способом описывать не только линию, а всё что угодно. Например написав <calendar></calendar> вы получили бы полноценный функциональный календарь. Естественно этот компонент еще необходимо создать или взять готовый. Весь фронтенд собирается как конструктор из набора таких компонентов.

Это можно сделать и на jquery. Но на jquery как правило получается спаггети-код, где бизнес-логика перемешивается вместе с DOM. В итоге бизнес-логику становится сложно тестировать и поддерживать. Angular позволяет спроектировать программу таким образом, чтобы отделить бизнес-логику от работы с DOM за счет двухстороннего связывания шаблона с компонентом.

Да, подключается на стороне клиента. У вас возникло непонимание, потому что код на angular принято писать на языке typescript. Браузеры этот язык не поддерживают и как следствие вы очевидно не можете запустить такую программу напрямую в браузере. Следовательно нужно скомпилировать код на typescript в javascript. Node.js здесь используется как инструмент, чтобы выполнять такое преобразование и на выходе получить готовый билд, который сможет исполняться в браузере. На продакшен вы будете выкатывать эти билды, а для разработки использовать исходники на typescript.

Если всё это пока слишком сложно, можете попробовать начать с vue.js. Идея абсолютно такая же, но избавляет вас от необходимости думать обо всем этом. Вы просто берете знакомый вам javascript и начинаете писать. Порог входа максимально упрощен. Люди осваивают vue также просто, как и jquery.

[ewb]

xfg, большое спасибо за столь развернутые и понятные ответы!

Answer 3

[Алексей]

Angular это просто фреймворк JS, но отличающийся от JQuery тем, что использует не императивный подход, а декларированый.
Node.js - это среда для работы JS, написанная на Си, и позволяющая в конечном итоге переводить JS-код в машинный код. Node.js не держит соединения постоянно с клиентом, (для постоянного соединения нужно использовать сокеты), но он предоставляет API для взаимодействия с устройствами ввода-вывода сервера.
Плюс в том, что вся тормоза интерпретируемых языков перемещается с сервера к клиенту, за счет чего, как правило, достигается прирост скорости. В Node.js много плюсов, но и появляются и минусы, главный образом связанных с тем, что поскольку всё это переместилось на фронтенд, то теперь программировать сайты стали те, кто раньше занимался версткой, со всеми вытекающими последствиями.

Comments

[Ptolemy_master]

тормоза интерпретируемых языков перемещается с сервера к клиенту,

Поясните пожалуйста, а что в данном случае клиент? Вы дальше пишите, что все там переместилось на фронтэнд, вот это тоже непонятно. Все равно все выполняется на серверной стороне, при чем тут фронтэнд? Спасибо.

[Stalker_RED]

Ptolemy_master, если мы про вэб, то клиентом чаще всего называют браузер пользователя.
И да, по сравнению с тем, что было лет 10-15 назад, нагрузка на фронт возросла, все чаще элементы бизнес логики переносятся поближе к пользователю, дабы увеличить отзывчивость.

Средний верстальщик из 2003 увидев эти ваши ангуляры ушел бы в длительный запой.

[ой всё]

Ptolemy_master, все выполняется в браузере
на бэкенде нынче делается минимум: валидация данных с клиента, данные в/из базы данных

ангуляр - это по сути очень неудачный шаблонизатор, который изначально был создан для верстальщиков, чтобы они могли изображать интерактивность, ну и посредственные разработчики ухватились за это "счастье" и теперь гнут пальцы, а бизнес логику как писали через одно место, так и пишут

[Ptolemy_master]

Stalker_RED, какое отношение браузер имеет к Node.js?

[Ptolemy_master]

ой всё, вопрос был про то, какое отношение Node.js имеет к фронтэнду и клиенту. Перечитав ответ еще раз, я поняла, что поняла его неправильно. Он имел в виду технологии в целом.
Что такое ангуляр, я тоже в курсе, уже года три как пользую его, и вполне довольна.

[Stalker_RED]

Ptolemy_master, примерно такое-же, как к php, python, ruby, или любому другому серверному коду.

[Толстый Лорри]

ой всё,

на бэкенде нынче делается минимум: валидация данных с клиента, данные в/из базы данных

Все, что произошло за последние 15 лет - это презентационная логика (трансформация и генерация HTML, грубо говоря) переместилась туда, где ее место - на фронте. На бэкенде как была бизнес-логика, так и осталась. Если приложение практически не содержит ее (лишь запись/чтение данных, без сложной обработки, вычислений по дороге), то и бэкенд вырождается в DAL.

[ой всё]

Толстый Лорри, сегодня бизнес логика на фронте, бэк остался с минимумом

[Толстый Лорри]

ой всё, окститесь, если в личном кабинете вашего интернет-банкинга авторизация и операции по вкладам будут происходить на фронте, то у меня для вас плохие новости) Критичные вещи, серьезные алгоритмы и валидацию на фронт не унесешь.

[ой всё]

Толстый Лорри, вы просто уносить не умеете
мне ничего не мешает проводить массу валидации на фронте и экономить клиентам массу времени, что не отменяет бэкенд валидации, как я уже писала выше

старайтесь внимательно читать комментарии, кэп :)

[Толстый Лорри]

ой всё,

вы просто уносить не умеете....мне ничего не мешает проводить массу валидации на фронте..., что не отменяет бэкенд валидации

Нет, ну вы по крайней мере старались)