Це нормальний дизайн, щоб повністю від'єднати веб-додатки для бекенда та інтерфейсу і дозволити їм спілкуватися з (JSON) REST API?

Я створюю новий веб-додаток для бізнесу і хочу досягти:

• Використовуйте найкращі технології у відповідних сферах. Я хочу надійну структуру бекенда з твердим ORM І я хочу, щоб найдосконаліша система SPA (для однієї сторінки) використовувала найсучасніші функції HTML та Javascript для додатка фронтальної програми.
• Викрийте суб'єкти господарювання та бізнес-сервіси для використання з різних типів додатків - наприклад, веб-додатків, мобільних пристроїв (Android) та, можливо, інших типів (розумні пристрої тощо)

Отже - щоб задовольнити обидві вимоги, я схильний повністю відокремити свою програму в додатках додатка та інтерфейсу та організувати зв’язок між ними за допомогою REST API (JSON). Це звуковий підхід?

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

Як я розумію, цілком відокремлений інтерфейс SPA зазвичай виникає через необхідність використання сторонніх API. Але чи є така звукова конструкція роз'єднання, коли і компанія, і резервний і фронтенд розробляються однією компанією?

Наразі мій вибір технологій - це Java / Spring backkend та Angular2 / Web Components / Polymer for frontend - якщо мені дозволять це сказати. Але це не має значення для цього питання, адже це питання стосується загальної конструкції, а не вибору конкретних технологій?

Це нормальний дизайн, щоб повністю від'єднати веб-додатки для бекенда та інтерфейсу і дозволити їм спілкуватися з (JSON) REST API?

Так, це нормально. Але це нормально лише в тому випадку, якщо вам потрібно мати такий спосіб поділу, і ви не змушуєте цю установку в загальній програмі.

SPA має кілька питань, пов'язаних з ним. Ось лише кілька, які зараз у мене на думці:

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

Звичайно, є і переваги SPA:

• повністю взаємодіють на передній частині з користувачем і завантажують дані лише за потребою з сервера. Так краща чуйність та досвід користувача;
• Залежно від програми, деяка обробка, виконана на клієнті, означає, що ви економите сервер цих обчислень.
• мати кращу гнучкість у розвитку епідемію та передньої частини (це можна зробити окремо);
• якщо ваш бек-енд по суті є API, ви можете мати інших клієнтів перед ним, як рідні програми для Android / iPhone;
• Розділення може полегшити розробникам інтерфейсу робити CSS / HTML, не потребуючи запуску серверного додатка на своїй машині.

Тож річ у тому, що в обох підходів є переваги та недоліки (SPA-сторінки проти серверів). Витратьте трохи часу на дослідження обох варіантів, а потім вибирайте, виходячи зі своєї ситуації.

Відповідь на ваше запитання проста. Так. Що ви пропонуєте - це обгрунтований підхід. Але тоді, що я думаю, ви хочете запитати - це кращий підхід, і, на жаль, ніхто з нас не може на це відповісти. Задіяні фактори охоплюють занадто багато аспектів, щоб, не розголошуючи все, що стосується вашої організації та вимог до продукту, не можна зробити реального висновку. Я думаю, ти вже знаєш, що робити.

Звичайна з застереженнями.

рамки JavaScript на передньому кінці обмежені тим, що вони можуть зробити. Якщо ви створюєте сировину apis для використання декількох додатків, вони зазвичай вимагають певної обробки сервера 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 викликається кодом на стороні сервера, ви не обмежені http-зв’язком. (хоча зараз це майже універсально)

Крім того, маючи javascript виклик того самого хоста, який він обслуговує, це означає, що вам не доведеться обмінюватися з допомогою корсів