Цель паблика не раскритиковать подход SPA, а показать какие есть альтернативы для реализации web приложения, основанного на API. Прошу обсуждать только сам подход, его минусы и плюсы.
Я придумал название для данного архитектурного стиля — newDHTML. Насколько оно подходящее — можете предложить другое.
Итак, newDHTML — архитектурный стиль разработки web приложений, это не фреймворк или библиотека. Идея возникла как альтернатива SPA по ряду причин, указанных ниже.
Single page application неплохой способ организации, но он имеет следующие минусы:
1.Сильно усложняет front-end часть приложения. Кроме html и логики UI тут еще и роутеры, MVC и прочие сладости.
2.Так как у приложения одна точка входа, существует риск того, что одна ошибка может привести к нерабочему состоянию всего приложения.
3. Дублирование роутеров (по сравнению с классическим подходом)
4. SEO
MVC-логика остается на серверной части. Ключевая особенность в том, что View возвращает статическую страницу, а вся динамическая часть собирается javascript-ом на стороне клиента.
Пример REST API:
Роутеры с суффиксом "-index" возвращают статическую верстку. Затем на этой странице подключаются ресурсы (css,js скрипты и другие). Далее js-компоненты подгружают динамические данные через REST API и пользователь видит окончательный результат.
API есть веб приложение, один раз написав приложение вы реализуете API.
Таким образом мы имеем веб приложение работающее полностью через API, но оно многостраничное и лишено нескольких недостатков SPA:
Во второй части планирую написать про компоненты. А пока всем спасибо за внимание и удачи!
Идея и текст автора.
Я придумал название для данного архитектурного стиля — newDHTML. Насколько оно подходящее — можете предложить другое.
Итак, newDHTML — архитектурный стиль разработки web приложений, это не фреймворк или библиотека. Идея возникла как альтернатива SPA по ряду причин, указанных ниже.
Single page application неплохой способ организации, но он имеет следующие минусы:
1.Сильно усложняет front-end часть приложения. Кроме html и логики UI тут еще и роутеры, MVC и прочие сладости.
2.Так как у приложения одна точка входа, существует риск того, что одна ошибка может привести к нерабочему состоянию всего приложения.
3. Дублирование роутеров (по сравнению с классическим подходом)
4. SEO
Идея
MVC-логика остается на серверной части. Ключевая особенность в том, что View возвращает статическую страницу, а вся динамическая часть собирается javascript-ом на стороне клиента.
API-эквивалент web-приложения
Пример REST API:
| Ресурс | GET | POST | PUT | DELETE |
|---|---|---|---|---|
| /books | список всех книг | новая книга | обновление всех книг | удаление всех книг |
| /books/1 | получаем книгу | обновление книги | удаление книги | |
| /books-index | возвращает статическую страницу html |
Роутеры с суффиксом "-index" возвращают статическую верстку. Затем на этой странице подключаются ресурсы (css,js скрипты и другие). Далее js-компоненты подгружают динамические данные через REST API и пользователь видит окончательный результат.
API есть веб приложение, один раз написав приложение вы реализуете API.
Таким образом мы имеем веб приложение работающее полностью через API, но оно многостраничное и лишено нескольких недостатков SPA:
- Более простая архитектура, каждая страница может иметь свои компоненты, свою логику и вообще работать как отдельный модуль со своей спецификой.
- В случаи ошибки на front-end — максимум поломается только одна страница из множества.
- Ну и другие плюсы, если заметите пишите.
Во второй части планирую написать про компоненты. А пока всем спасибо за внимание и удачи!
Идея и текст автора.
