Philipp

Про то, что Docker умирает пишут малообразованные.
Docker очень даже живет, просто он изменил политику предоставления услуг и стал предоставлять свои технологии за денежку.
На мой взгляд Docker единственный приемлемый вариант для развертывания разного рода сервисов с разветвленной архитектурой. Вкупе с Docker Compose вообще идеальный вариант.

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

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

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

Я так понимаю, никаких здоровых процессов по развертывания проекта у вас нет. Советую присмотреться к какой-нибудь CI, даже тот же Deployer облегчит вашу жизнь. Он прекрасно работает в связке с Laravel.

У меня впечатление того, что вы не совсем понимаете, что такое NPM и Node.js.

Для начала нужно разобраться с понятиями клиента и сервера. Клиент - это браузер, сервер - то, откуда клиент получает ресурсы. Ресурсы - это html, css, js (созданный для выполнения на клиенте).

Node.js - это реализация движка Javascript (того самого, который в бразуере), но с применением его на стороне сервера.

Javascript - это просто язык программирования, но код, написанный на нем, может выполняться в разных средах, т.е. на стороне сервера (node) или на стороне клиента (браузер). Этот код очень похож, но имеет некоторые отличия.

npm - это пакетный менеджер, упрощенно его задача скачивать архив с кодом и распаковывать в node_modules.

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

По умолчанию npm пакеты сделаны для работы с Node.js движком. Для того, чтобы их содержимое можно было правильно использовать на стороне клиента, придумали различные ухищрения - сборщики. Их задача адаптировать Node.js код для выполнения на стороне клиента. Попутно они делают еще много чего, например разного рода оптимизации и т.д.
В вашем случае нужно использовать наиболее популярные сборщики - webpack подойдет для старта.

npm - отличный инструмент для быстрой установки зависимостей, библиотек и т.д. Но им нужно научиться пользоваться. Есть еще nvm - управление версиями Node.js, тоже надо.

Дам вам совет - посмотрите https://learn.javascript.ru/screencast/nodejs и разберитесь, что и в каком контексте выполняется. Там же вы найдете пояснения по поводу npm.
Советую пройти https://ru.hexlet.io/courses/js-setup-environment (это бесплатно).
И это под конец https://learn.javascript.ru/screencast/webpack

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

3. При заказе на моем сайте будет автоматически идти заказ в другом магазине

Так делать не стоит с юридической точки зрения. Вам нужно указывать посредника.
С технической точки зрения система автоматизации заказа реализуется через API магазина посредника. В данном случае вы несете ответственность за обработку и хранение данных пользователей со всеми вытекающими.
Это сложно, долго и дорого. Готовы? Если нет, то промо-код и реферальные ссылки для вас самое то.

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

Обычно для счетчиков стараются применять базы данных в памяти.
В основном это Redis, но можно и MySQL использовать, просто указать хранилище в памяти и отключить транзакции.
В большинстве своем счетчики обновляются на основе различных событий, например отправка комментария. Обновление делается в фоновом режиме.
Как только данные актуализируются, интерфейс уведомляется о новом состоянии счетчиков. На больших сайтах это реализуется через SSE или веб-сокеты.

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

А зачем вообще высокое качество кода, если его кроме своих больше никто не видит?
Это ваш первый фактор, который сильно влияет на мотивацию разработчиков. Их работа по большому счету никому не нужна.

Тестов нет, я сам вручную тестирую закрытые таски на предмет ошибок.

Дальше можно не продолжать. Отсутствие тестов - индикатор низкого уровня разработки, как результат - плохой код на выходе. Это ваша вина, как лидера группы.

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

Очевидно для вас, неочевидно для разработчика. Реализация напрямую зависит от постановки задачи. Если вы предоставили плохое/нечеткое ТЗ, то будут косяки. Опять же ваша вина.

Разработчик должен пушить код, в котором он уверен с высокой степенью вероятности или это так и принято, что пушишь и нифига не тестируешь, типа как-то там сами тестеры разберутся?

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

Что посоветуете?

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

Итак, что же нужно сделать в такой ситуации.

0. Поговорить с людьми, чисто по-человечески. Объяснить, что от их работы зависит работа компании и их зарплата, премии и т.д. Внедрить понимание культуры ответственности и гордости за сделанную работу. Поощрять хорошо сделанную работу. Еще нужно уметь разбираться в психологии людей, вникать в их проблемы (дети, болезни, долгая дорога), помогать быть успешными в своей работе. Человеческое отношение творит чудеса - люди сами станут стараться делать свою работу хорошо.

1. Пересмотреть подход к постановке задач. Недаром в Agile имеется такой пункт, как сценарий использования. Это и есть ваш тест. Если разработчик выполняет сценарий и баг возникает, значит его косяк. Решается возвратом тикета на доработку. Если тестовый сценарий хоть на йоту отличается - ваш.

2. Внедрить юнит и интеграционное тестирование, как часть процесса разработки. Разработка будет в 2-3 раза дольше. Это нормально. Зато качество кода существенно улучшится и количество ошибок уменьшиться. Внедрение тестирования достаточно болезненный этап и занимает около года на перестройку мышления.

3. Следует научиться разбираться в людях. Это сложно. Есть люди, которые делают больше ошибок, чем другие. Как правило они имеют творческую натуру. Они чаще нарушают правила, делают что-то не так, как все и т.д. Вобщем чудаки по жизни. В работе такие люди создают много ошибок и сами это знают, но они не в состоянии с этим ничего сделать. Тяжелее всего таким людям дается рутинная работа. Для них это боль, для руководителя одно расстройство. Однако у этих людей есть одно качество, которое перевешивает остальные - они способны решать задачи нестандартными способами. Эти люди могут придумать нечто новое, такое, чего еще никто не делал. Такие люди, сами того не понимая, могут сделать какую-то фичу, которая будет выгодно отличать ваш продукт от конкурентов. Нельзя собирать команду сплошь из таких людей, она будет нефункциональна.

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

Напоследок. Ошибки бывают даже при самых лучших практиках и замечательной мотивации. Это природа человеческой натуры. Не будьте чересчур строги к подчиненным.

Совместите приятное с полезным https://github.com/avelino/awesome-go

Существует понятие цикла релизов. Каждый цикл подразумевает детерменированное количество изменений внесенных в продукт.
Для каждого релиза объявляется набор интерфейсов между компонентами. В разных проектах это реализуется по-разному, например в веб используются инструменты вроде Swagger.
Есть архитектор, который отвечает за общий интерфейс. Он объявляет версию, например 1.0.5. Бэкенд и фронт-энд пилятся под соответствующую версию интерфейса. Если одна команда не успевает, происходит релиз 1.0.4, т.е. то, что готово или релиз откладывается.
Обычно может быть объявлено несколько версий интерфейса.
В больших и сложных проектах используется модульный подход. Каждая команда отвечает за свой компонент проекта и имеется координатор проекта. Он отвечает за релиз. В любом случае подготовленный релиз проходит через команду тестировщиков и т.д. Просто так сырой код в продакшен не попадает.

Добавить третью таблицу - message_status.
В ней хранить message_id, user_id и read_at в виде nullable timestamp.
В интерфейсе чата контролировать сообщения попадающие в видимую область и отслеживать событие прокрутки.
Сохранять статус сообщений в модели на клиенте и периодически отправлять эти обновления на сервер в фоне и по page unload если что-то осталось.

Начнем с простых технических требований.
Хранение данных. В современном мире фильм среднего качества хотя бы в 720p занимает 1 GB/Hr. Т.е. 2 GB на киношку. 50 фильмов = 100 GB на жестком.

Я рекомендую остановиться на 256 GB SSD. SSD необходим по 2-м причинам - работа в автобусе предполагает значительное количество вибраций, что будет приводить к выходу из строя обычных жестких дисков, кроме этого многопоточный стриминг требует доступа к 20 различным файлам одновременного доступа на довольно значительном рейте, чего не может вам дать обычный жесткий диск.
По поводу остальной части компьютера - лучше всего брать какой-нибудь мини-компьютер без вентилятора, типа такого. Без вентилятора очень важно ибо запаритесь чистить пыль и менять вентиляторы. К компу обязательно переобразователь-стабилизатор от борт-сети автобуса. Можно такие поискать на AliExpress, но лучше найти электронщиков/радиолюбителей, они сделают все правильно.

По поводу сети получается от 2.5 MBit/s на клиента. Плюс для поддержки авторизации и странички потребуется captive portal. Для стабильной раздачи на такой скорости для такого количества клиентов обычные домашние точки доступа не подойдут, нужны точки доступа корпоративного уровня. Я советую присмотреться к двухдиапазонным точкам от Ubiquiti или Microtik. Задача точки доступа просто перенаправить человека на сервер.

В плане софта для сервера однозначно Linux, nginx + hls + mp4 streaming. Видео обязательно переконвертировать в mp4 c оптимизацией для веб. Для сервера нужно будет написать небольшой скриптик, который обойдет директории с фильмами и сгенерирует индекс плюс по небольшой страничке под каждый файл.

Поскольку в самих ПК тоже есть wi-fi, их можно настроить на подключение к домашней "межавтобусной сети". Смысл ее заключается в простой вещи. На каждый компьютер устанавливается syncthing, который будет синхронизировать ролики между компьютерами. Т.е. достаточно будет положить видео на один компьютер и все остальные синхронизируются между собой. Не очень быстро, но просто в обслуживании.

Если очень хочется современных решений, то смотрите сюда https://mobileonboard.com/beam-bus-wifi-systems/ и здесь https://www.quora.com/What-is-the-best-system-for-...
Но тема такая, что вам нужно специализированный программно-аппаратный комплекс. Увы, стоить он будет дороже автобуса. Просто по-хорошему нужно взять комп и точку доступа, собрать к ним адаптеры по питанию, засунуть все в нормальный, стойкий к вибрациям и перепадам температур корпус. Да еще и приладить к этому всему софт. Несмотря на внешнюю простоту, это сложное техническое решение.

Читайте документацию https://developers.facebook.com/docs/pages/realtime
Там есть все необходимое.

Есть неплохой российский проект https://pushall.ru/