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

21

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

  • Используйте лучшие технологии из соответствующих областей. Я хочу надежный каркас с твердым 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 для внешнего интерфейса - если мне позволено это сказать. Но это не имеет отношения к этому вопросу, потому что этот вопрос касается общего дизайна, а не выбора конкретных технологий?

Мистеру
источник
8
(1). Да. Это нормально, теперь дни идут по этому пути.
Laiv
5
(2). So - I must be cautious when starting to use technologies in manner which is not widely used.Да, вы должны быть осторожны, если вы планируете использовать молоток, чтобы разбить шелк. Может быть, это не тот инструмент.
Laiv
3
Имейте в виду, что разделение таким строгим образом создает значительные начальные затраты на разработку. Вы должны извлечь из этого какую-то конкретную ценность.
USR
2
Также обратите внимание, что вы никогда не можете напрямую выставлять свой домен браузеру. Это создает проблемы безопасности, и данные не будут соответствующим образом отформатированы для отображения. Вам нужно будет создать специальный интерфейс (REST) ​​только для вызова JavaScript. И это в сочетании.
USR
1
Spring имеет аннотации PathVariable, ResponseBody, RequestBody и RestController (Вы должны проверить их). Они делают разработку веб-приложений JSON / REST на основе Ajax очень и очень простой, что делает Spring отличным бэкэндом для SPA. Я твердо верю, что такое разделение внешнего интерфейса и внутреннего интерфейса - лучший выбор: классические приложения JSF, с которыми мне было приятно работать, были беспорядочными.
Traubenfuchs

Ответы:

14

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

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

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

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

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

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

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

Богдан
источник
11
«безопасность труднее сделать, когда весь код находится на клиенте»; эм, разве большое преимущество не в том, что безопасность легче сделать, потому что это очень прозрачный слой, который вы должны защищать, который разработан логичным и простым для понимания способом.
Дэвид Малдер
3
@DavidMulder: с прозрачным слоем безопасность сложнее сделать вообще, но легче сделать правильно. Без четкого разделения вы можете сделать что-то правдоподобное, но неправильное в кратчайшие сроки ;-)
Стив Джессоп
1

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

samazi
источник
0

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

рамки 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

Ewan
источник