Лучшая практика: развертывание приложения Angular и Spring REST Api

Я пытаюсь развернуть угловое приложение, которое взаимодействует с API пружинного упора.

Приложение Spring размещено на tomcat и работает как положено.

Мое угловое приложение - простая форма, которая также работает в теории. Теперь я пытаюсь развернуть обе системы в моей локальной системе и отправить данные угловых записей на сервер Tomcat, где они будут обрабатываться приложением Spring.

Поскольку это будет чем-то, что я буду постоянно развивать в течение следующих месяцев, я ищу советы по передовым методам развертывания. Рекомендуется ли подавать оба из контейнера tomcat, или должно быть разделение интересов? В этом эксперименте я также надеюсь узнать о масштабируемости и архитектуре, поэтому, используя отдельные vms, несколько серверов, балансировку нагрузки и т. Д., Я стремлюсь понять и получить любые полезные советы или указания в правильном направлении. Спасибо.

7 голосов | спросил Catresl 11 J0000006Europe/Moscow 2017, 19:35:38

1 ответ


0

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

Вы сделали первый шаг вправо.

Вот мой опыт и то, что я могу смело сказать в качестве «рекомендуемой» настройки:

  • Angular приложение и Spring

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

  • Вы упомянули, что эти компоненты будут постоянно развиваться. Обычно они развиваются отдельно. Это лучший вариант для отдельных конвейеров развертывания (для их создания и развертывания отдельно).

  • Приложение Angular может быть размещено в node сервер, в то время как бэкэнд API на основе Spring работает на экземпляре Tomcat. Это также поможет вам сбалансировать нагрузку этих компонентов по отдельности в зависимости от того, какой компонент требует большего внимания.

  • Из-за этого разделения полное приложение не отключается во время простоя. API REST могут быть недоступны для обслуживания или из-за ошибки, но пользовательский интерфейс приложения все еще может работать и обслуживать некоторые запросы, которые не зависят от серверной части. Это намного лучше, чем приложение, которое вообще не доступно.

  • Такие методы, как переключение функций, могут использоваться на уровне пользовательского интерфейса для отключения некоторой части функциональности, которая зависит от серверной части или выполняется наполовину. Хотя это можно сделать в одном развертываемом приложении, гораздо понятнее понимать и управлять, когда пользовательский интерфейс отделен от логики бэкэнда. Бэкэнд может иметь свою собственную структуру переключения функций (отличную от той, что на уровне пользовательского интерфейса).

  • В будущем вы можете открыть API REST для внешнего мира (или других приложений) и добавить дополнительные сервисы, которые могут не потребоваться для вашего приложения Angular. Потенциально специальная группа может работать с компонентом API REST в настройке, и может иметь смысл не предоставлять их в Angular-код.

  • Мой любимый: рассматривайте общедоступный Angular-компонент вашего приложения как «клиента» для вашего Spring-приложения (REST API). Это делает приложение REST «универсальным» и слабо связанным с компонентом Angular, который в долгосрочной перспективе имеет огромные преимущества.

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

ответил iCrus 11 J0000006Europe/Moscow 2017, 20:30:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132