Philipp

Примерно так

Почитайте документацию
mongodb.github.io/mongo-java-driver/2.13/getting-s...

Чтобы решить проблемы, которые у вас существуют, нужно сделать 3 вещи, но планомерно и плавно.
1. Обучите программистов такой вещи, как git. Подождите с недельку. Затем просто прогоните их по циклу - откати эти изменения. Верните изменения. Ну раз 5, с дедлайном вчера. Все, кто не будет пользоваться git, будут мучаться часами и днями. Напомните им, как легко это делается с помощью git. Повторите испытание через некоторое время. Поставьте ультиматум: git или идите искать новую работу. Кстати, у каждого человека должен быть свой отдельный аккаунт.
2. Держите репозитарий для проекта целиком. Сделайте отдельные папки для исходников верстки, для собранной верстки и самого сайта. Верстальщики работают со своими папками. Собирают верстку и коммятят собранную верстку в отдельную папку. Программисты через историю коммитов смогут отследить изменения и внести их назад в разработанные компоненты.
3. Реализуйте автоматизированное развертывание проекта и запретите редактирование файлов через FTP/минуя git.

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

lollyrock.com/articles/nodejs-encryption

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

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

Часть первая, добрая

1. Идете к юристу и оформляете правильную лицензию, в которой вы предоставляете право на использование вашего продукта. Жестко запретите модификацию кода CMS всеми, кроме вас. Оставьте за собой право модификации кода удаленно, в любое время без предварительных уведомлений. Оставьте за собой право отзыва или изменения лицензий без уведомлений и объяснений. Запретите перепродажу. В лицензии добавьте оговорку насчет статьи 273, что действия по модификации кода сайта являются санкционированными и неотъемлемой частью продукта.
2. Реализуете и обкатываете механизм автоматического лицензирования через интернет. Вешаете лицензионное соглашение на официальный сайт продукта.
3. Рассылаете всем нелицензионным пользователям "письмо счастья", в котором доходчиво объясняете, что их копия не лицензирована и т.д. Рекомендую вам разрешить использование своей CMS для некоммерческих организаций и домашних страничек без рекламы при наличии ссылки на сайт продукта. Предложите бесплатное обновление для некоммерческих пользователей.

Часть вторая, злая

1. После введения новой лицензии, но до уведомления всех письмами счастья, удаленно зашиваете код, который будет выводить html-комментарий о том, что данная копия не имеет лицензии т.д. и т.п. Там же должна быть ссылка на ваш сайт, где можно лицензировать продукт. Данный шаг не будет препятствовать работе с сайтом.
2. Рассылаете письма счастья.
3. Ждете, пока пройдет срок, в течение которого компании должны лицензировать свои версии.
4. Вместе с юристом выбираете компанию, на которую вы подадите в суд за нелицензионное использование своей CMS и у которой точно выиграете дело. Судитесь. Выигрываете. Далее на сайте проекта вешаете официальную информацию о судебном разбирательстве и решении в пользу истца. Делаете огласку истории, публикуете ее на всяких Спарках/Хабрах/Цукербергах и прочих ресурсах.
5. Через месяцок рассылаете новые письма счастья с уведомлением о том, что бывает с теми, кто отказался. Ссылку на результаты разбирательства приводите.
Плюс, можете вывесить список сайтов у себя, где нелегально используется ваша CMS.

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

Часть третья, плохая

Для всяких нехороших людей, ничего из себя не представляющих и пишущих маты вам в ответ, включайте 404-ю для поисковых роботов. Они очень громко будут вас ругать на форумах. Не обращайте внимания.

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

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

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

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

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

Для marketing api - несколько тысяч в день не проблема.
Зависит от того как вы используете его. Так же вам потребуется заапрувить приложение до уровня Standard.