Является ли нормальным проектирование, позволяющее полностью отделить внутренние и внешние веб-приложения и позволить им взаимодействовать с (JSON) REST API?

Я создаю новое бизнес-веб-приложение и хочу добиться:

• Используйте лучшие технологии из соответствующих областей. Я хочу надежный каркас с твердым ORM. И мне нужна самая совершенная инфраструктура SPA (одностраничное приложение) с использованием самых современных функций HTML и Javascript для приложения веб-интерфейса.
• Предоставлять бэкэнд-сущности и бизнес-сервисы для использования из различных типов приложений, например, веб-приложений, мобильных устройств (Android) и, возможно, других типов (интеллектуальные устройства и т. Д.).

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

Такое разделение не является очевидным дизайнерским решением, потому что многие технологии веб-приложений имеют интегрированные слои представления, где приложение на стороне сервера более или менее контролирует генерацию представления и частично обрабатывает ответы от представления (например, SpringMVC с уровнем представления, PHP Yii с представлением слой Java JSF / Facelets полностью сохраняет состояние своих компонентов на сервере). Итак, существует множество технологий, которые предлагают более прочную связь и обещают более быстрое время разработки и более стандартный путь прохождения. Поэтому я должен быть осторожен, когда начинаю использовать технологии не так широко.

Как я понимаю, полностью разделенный интерфейс SPA обычно возникает из-за необходимости использования стороннего API. Но разве такой разъединяющий звуковой дизайн, когда и backend и frontend разработаны одной компанией?

В настоящее время я выбираю технологии на основе Java / Spring backend и Angular2 / Web Components / Polymer для внешнего интерфейса - если мне позволено это сказать. Но это не имеет отношения к этому вопросу, потому что этот вопрос касается общего дизайна, а не выбора конкретных технологий?

Является ли нормальным проектирование, позволяющее полностью отделить внутренние и внешние веб-приложения и позволить им взаимодействовать с (JSON) REST API?

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

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

• это в основном JavaScript. Одна ошибка в разделе вашего приложения может помешать другим разделам приложения работать из-за этой ошибки Javascript. На страницах, обслуживаемых с сервера (SpringMVC, PHP и т. Д.), Вы перезагружаете новый раздел;
• CORS . Не обязательно обязательно, но часто серверная часть находится на другом доменном имени, чем интерфейсная. Так что теперь вам приходится иметь дело с проблемами безопасности браузера;
• SEO . Тебе это нужно? Ваш сайт публичный? Google может понять Javascript и попытаться разобраться в вашем сайте, но вы в основном предоставляете контроль боту и надеетесь на лучшее. Возвращение контроля может означать необходимость полагаться на другие инструменты, такие как PhantomJS .
• отдельное интерфейсное приложение означает отдельные проекты, конвейеры развертывания, дополнительные инструменты и т. д .;
• безопасность сложнее сделать, когда весь код находится на клиенте;

Конечно, есть и преимущества SPA:

• полностью взаимодействовать во внешнем интерфейсе с пользователем и загружать данные только с сервера. Так лучше отзывчивость и пользовательский опыт;
• в зависимости от приложения некоторая обработка, выполняемая на клиенте, означает, что вы избавляете сервер от этих вычислений.
• иметь большую гибкость в развитии back-end и front-end (вы можете сделать это отдельно);
• если ваш бэкэнд по сути является API, у вас могут быть другие клиенты перед ним, такие как нативные приложения для Android / iPhone;
• Такое разделение может облегчить разработчикам интерфейсных приложений работу с CSS / HTML без необходимости запуска серверного приложения на их компьютере.

Итак, дело в том, что у обоих подходов есть свои преимущества и недостатки (SPA или страницы сервера). Потратьте некоторое время на изучение обоих вариантов, а затем выберите в зависимости от вашей ситуации.

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

Нормально с оговорками.

рамки javascript внешнего интерфейса ограничены в своих возможностях. Если вы создаете raw apis для использования несколькими приложениями, они обычно требуют некоторой обработки на стороне сервера вызовов raw api в модели представлений, которые работают с этим конкретным приложением.

Следовательно, «нормальная» архитектура может быть:

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

Теперь, если у вас есть только одно веб-приложение, вы можете вырезать слой «API-интерфейс, раскрывающий API-интерфейс» и просто заставить серверный веб-код напрямую вызывать бизнес-логику.

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

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

Кроме того, наличие javascript для вызова того же хоста, с которого он обслуживается, означает, что вам не нужно возиться с cors