Alex

1. Если функция использует хуки или привязана к хукам — отвязать и присоединить свою функцию.
2. Если выводится в шаблоне — переопределить шаблон.

cron

(angular не использует vdom, для него история другая)

перерисует целиком свой виртуальный dom

Давайте немного проясним: виртуальный DOM - это грубо говоря js объект содержащий другие объекты.
При добавлении нового сообщения туда добавится новый объект и весь DOM сравнится со старой версией с помощью diff-алгоритма специфичного для конкретного фреймворка.
И только результат этого сравнения добавится в реальный DOM.
Работа с объектом значительно быстрее работы с самим DOM-ом, поэтому чтобы оно начало работать заметно медленее у вас должен быть дикий уровень вложенности или очень большой DOM.

100 сообщений и 50 контактов - это небольшие цифры, с таким любой из упомянутых фреймворков справится без просадок.

Вот пример бенчмарков с большим количеством объектов(1000+) для многих фреймворков на примере незамысловатой таблицы:
www.stefankrause.net/js-frameworks-benchmark6/webd...
(там же есть ссылка на репо чтобы увидеть как она выглядит)
Как видите, там в таблицу уже содержащую 10 000 добавляется еще 1000(!) объектов, и многие фреймворки впонле с этим справляются.

В реальности же, вам вряд-ли придется добавлять такие цифры, потому что подгружают изначально обычно меньшее количество: такое, которое пользователь сможет увидеть в одном экране, все остальное догружается постепенно по мере надобности. То же самое касается вашей истории чата, ее стоит подгружать только за тот период, за который она необходима пользвателю.

Вопрос поставлен некорректно, так как Node.js никак не альтернатива Angular.
Изучайте Node.js и React.
Node для бека, React для фронта.
Можно посмотреть на Vue как альтернативу React, порог входа там ниже.
Но комьюнити и экосистема у React больше.
Angular тяжеловат для новичка, порог входа повыше, а научиться писать на нем правильные вещи тяжелей.
Лучшая IDE для JS и фронтенда в частности Webstorm

jwt в первую очередь используется в микросервисных архитектурах, когда конечный клиентский запрос будет обрабатываться одним из нескольких серверов.

Классически в такой архитектуре использовали механизмы OAuth. которые при обслуживании каждого запроса клиента осуществляли запрос на сервер OAuth - "клиент с токеном ААА запрашивает выполнение действия БББ"

Понятно что узким местом становится сервер OAuth - который должен выдержать "шторм" запросов при нагрузке. Вторым узким местом такой архитектуры становится увеличение времени ожидания ответа на запрос - внутри запроса как минимум будет выполнен 1 запрос авторизации.

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

JWT решает эти проблемы следующим путем: access токен сразу же содержит необходимую информацию: на пример о Ролях текущего пользователя, или о доступных ему действиях, кроме того предоставляет информацию о времени жизни этого токена. Обязательно в конце токена цифровая подпись. По ней собственно и проверяется "действительность" токена.

Алгоритм прост:
1. осуществить авторизацию - получить ответ 2 токена access, refresh.
2. обращаемся к микросервисам с использованием access токена.
3. если необходимо с помощью refresh токена обновляем access токен.
4. когда и refresh токен истек - осуществляем повторную авторизацию.

Где хранить JWT токен - где угодно. все зависит от инструментов и реализации. На пример можно реализовать хранение токена в LocalStorage, и пробрасывание его во время каждого запроса в виде header'а. Если один и тот же домен - то токен можно хранить в cookie и т.д.

Что хранить в виде полезной нагрузки? Сам разработчик должен для себя решить какой объем информации публиковать в таком токене, кроме того стоит учитывать что информацию из токена можно прочитать - это просто base64 кодированная JSON строка...

1. Не нужно пересобирать вендоров на каждый чих.
   
2. Не нужно минифицировать на каждый чих.
   

Есть два режима работы скриптов — development и production.
В режиме разработки вы не пересобираете вендоров вотчером, подключаете два файла в html (условно vendor.js и main.js), генерируете сорс-карты, не минифицируете код.
Когда всё готово, вы собираете билд для сайта — клеите всё в один файл, минифицируете код, отключаете сорс-карты.

Во-первых, у Nginx очень высокая производительность при очень низкой требовательности к ресурсам сервера. В вашей схеме сотня тысяч одновременных запросов на статику будет обработана в разумный срок и никак не скажется на производительности бэкенда. В схеме заказчика, тормозить начнёт и отдача статики и бэк, не исключено, что сервер вообще перестанет отвечать на запросы.

Во-вторых, Nginx очень надёжный и безопасный. Не в последнюю очередь потому, что в базовой комплектации прост как кирпич. Обеспечение того же уровня устойчивости к взлому для IIS, требует существенно больших умений и трудозатрат админа.