Philipp

lollyrock.com/articles/nodejs-encryption

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

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

В одностраничном приложении (SPA) присутствует единая точка входа. Это загрузка основного скрипта, который будет отвечать за логику работы приложения. Это как index.php в корне веб-сайта. Ну а дальше он уже сам решает, что делать. В основной скрипт обычно включены составляющие отвечающие за маршрутизацию и загрузку других частей приложения. Вы можете представить себе SPA как набор кирпичиков с раствором в виде основного скрипта.
Так вот эти кирпичики могут быть загружены сразу, а могут лишь в тот момент, когда они потребуется, примерно как Autoloader в Composer.

Относительно загрузки есть несколько разных подходов.
1. Когда грузится только загрузчик и затем остальные скрипты и шаблоны подгружаются по необходимости.
2. Когда все (скрипты+шаблоны) собирается в огромный JS-файл. Это файл потом работает.
3. Когда JS идет большим файлом, а шаблоны отдельно (так работает AngularJS 1).

Есть множество различных сборщиков, например WebPack, Gulp, Brunch, Grunt. Их вариаций много, не пугайтесь.

После начальной загрузки приложение решает, что должно быть запущено первым. Обычно это какие-то системные вещи, вроде загрузки шаблонизатора, всяких кэшей и роутера.
Далее роутер рабирает маршрут и запускает нужный модуль (контроллер/компонент); в зависимости от фреймворка это выглядит по-разному, но суть одна и таже.
Каждый компонент отвечает за модификацию отдельных узлов дерева состояний, которое так или иначе спроецировано на DOM. Если смотреть на бэкенд, это как подставлять в шаблон данные, только на бэкэнде это происходит в один проход, а здесь перестройка происходит сразу после изменения оригинальных данных.
В каждом феймворке это сделано по-своему. Смысл одинаков - проекция данных на DOM.
Данные вытаскиваются приложением самостоятельно, могут быть загружены через Ajax. У меня есть приложение, где транспорт идет через веб-сокеты. Можно даже через iframe заморочиться, это не имеет значения.
Иногда сервер отдает страничку с изначально подготовленными данными. Это делается в разных целях, в основном для уменьшения скорости старта приложения.

Из личного опыта скажу, что вам следует начинать с Angular 2, т.к. он сделан намного проще остальных в плане использования.

Да, использование пула соединений поможет вам избежать подобной проблемы.

Рекомендуется также изменить размер количества одновременных соединений (max-connections) в настройках MySQL.

jQuery, элементарная замена класса.

Прочитайте это раздел целиком https://developers.facebook.com/docs/javascript

Подключите Javascript SDK.
Установите приложение себе и получите токен пользователя. Вызовите ваш с полученным токеном пользователя.

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

FB.api(
  '/10154092833240172',
  'GET',
  {"fields":"reactions.type(LIKE).summary(total_count).limit(0).as(like),reactions.type(LOVE).summary(total_count).limit(0).as(love),reactions.type(WOW).summary(total_count).limit(0).as(wow),reactions.type(HAHA).summary(total_count).limit(0).as(haha),reactions.type(SAD).summary(total_count).limit(0).as(sad),reactions.type(ANGRY).summary(total_count).limit(0).as(angry)"},
  function(response) {
      // посмотрите, что приходит в ответе
     console.log(response);
     // затем используйте любимый способ для интерполяции данных и html
  }
);

Если ты не понимаешь теорию, значит на практике у тебя ничего стоящего не выйдет.
А так вполне себе хорошая теория тут https://developer.mozilla.org/en-US/docs/Web/API/P...
И она содержит ссылочку на вполне себе реальный пример https://github.com/chrisdavidmills/push-api-demo

Как эта штука используется на практике.

После того, как вы определились с тем, что вы собираетесь отправлять, вам нужно сделать несколько вещей.
1. Запросить у пользователя разрешение на отправку уведомлений. Делается это через Notification.requestPermission. Если мы получили подтверждение, то идем дальше, если нет, забиваем на это дело. Здесь нужно быть очень осторожным и делать это ненавязчиво.

2. Создать фоновый обработчик, который будет принимать push-уведомления от сервера. Это делается через вызов navigator.serviceWorker.register. Например так https://github.com/chrisdavidmills/push-api-demo/b...
Он подписывается на канал. Канал - это как комната в чате.

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

3. Написать сервер уведомлений. У nginx есть хороший модуль. Он будет обслуживать клиентов.

Рекомендую к просмотру https://www.youtube.com/watch?v=5A5Iw9z6z2s

Вы неправильно рассматриваете систему чатов.
В чатах есть комнаты, внутри комнат сообщения и участники.
Тет-а-тет это приватная комната с 2-ми участникам.

room 
- id
- name
- private

participant (участник чата)
- id
- name

roster (список участников чата)
- room_id
- participant_id

history (история сообщений)
- id
- room_id
- participant_id
- timestamp
- type (тип сообщения, иногда нужны системные сообщения от ботов)
- text
- deleted

А теперь вперед - учить JOIN'ы!

По поводу нагрузки - при правильном проектировании приложения, нагрузка на базу будет минимальной, преимущественно проверки, кто принадлежит к какой комнате и запись в историю.
Сколько-нибудь значимая нагрузка будет при 10к человек онлайн. Поверьте, это очень большая посещаемость.
При большей посещаемости ваша проблема будет решена горизонтальным масштабированием (шардингом БД).

https://github.com/Ninjakannon/Cloudgen.js + jsfiddle.net/qfEUt