Методы разделения передней и задней части с полным стеком JavaScript?

Предположим, у меня есть интерфейс, который в основном представляет собой одностраничное приложение, написанное с использованием angular, grunt и bower. И предположим, у меня есть бэкэнд, который в основном представляет собой просто REST API, расположенный поверх ORM, который хранит / извлекает объекты из базы данных, используя такие вещи, как grunt, express и sequelize.

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

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

У меня вопрос, какие существуют методы для этого чисто? Есть ли рекомендуемые лучшие практики для полного стека javascript?

Вариант № 1 кажется монолитным, то есть «не разделяйте их». Преимущество состоит в том, что цепочка сборки проста, и все в одном месте, но, похоже, есть много минусов; Более сложная версия независимо, сломанный фронт означает неразвертываемую заднюю часть и так далее.

Вариант № 2 кажется квазимонолитом, в котором цепочка сборок внешнего интерфейса приводит к записи группы файлов на внутренний конец. distКаталог на переднем конце будет ссылаться на какой - нибудь каталог на спине конца, так , по существу , когда передний конец minifies, uglifies и т.д., он заканчивает публикацию к фоновым, который проходит все.

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

Вариант № 4 может заключаться в использовании чего-то вроде docker-compose для объединения всего этого.

Я уверен, что есть другие варианты. Какова рекомендуемая лучшая практика?

Это интерфейсное, фоновое приложение с промежуточным REST-интерфейсом. У вас уже есть полное разделение.

Мой голос за вариант № 3. Вы, кажется, беспокоитесь о конфигурации, но в этом вся суть. Конфигурация позволяет вам иметь полное разделение, не требуя тесно связанных привязок кода. Если вы беспокоитесь о CORS, поместите все в один домен. Если у вас есть CORS, лучшим способом управления является конфигурация.

Но здесь нет «лучшей практики». Лучшая практика - это та, которая наилучшим образом соответствует вашим конкретным потребностям.

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

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

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

Редактировать: что касается полных стеков JS лучших практик - я бы просто сказал, чтобы быть последовательным. Если вы используете обещания (и вы должны), делайте это с обеих сторон. Сохраняйте тот же стиль и форматирование js, используйте те же библиотеки тестирования (где это возможно) и т. Д.