Я придумал название для данного архитектурного стиля — 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 — максимум поломается только одна страница из множества.
- Ну и другие плюсы, если заметите пишите.
Во второй части планирую написать про компоненты. А пока всем спасибо за внимание и удачи!
Идея и текст автора.
Комментарии (116)
napa3um
07.09.2016 01:17+4Вы придумали «архитектуру», на которой уже базируется ~90% сайтов всего видимого интернета (т.е., «нехипстерская» его доля), и к которой толкает PHP «by design» (особенно без MVC-фреймворков, когда роутер — это файловая система и иногда плагин mod_rewrite).
nickorsk
07.09.2016 11:29-3Может и не я это придумал))
Эта архитектура зародилась в работе и не только моей.
zoonman
07.09.2016 01:28+1Ваша идея очень похожа на rails-turbolinks gem.
На самом деле идея SPA растет из одной большой идеи — держать общее API для взаимодействия нескольких платформ, например одно и тоже API может использоваться SPA, iOS App, Android App и иметь какой-нибудь SOAP-фасад для Delphi или других интеграций.
Если вы почитаете описания многих фреймворков, то обратите внимание на их модульность и возможность комбинирования компонентов. Совсем не обязательно создавать одно большое SPA, иногда его можно разделить на несколько более мелких частей.nickorsk
07.09.2016 09:18-1Да SPA именно для этого создавалась. НО это единственный подход для построения приложения, базирующегося на API?
Если на нескольких страницах использовать «SPA» — это уже не SPA, так как это уже не одностраничное приложение( Single Page Application)
webmasterx
07.09.2016 04:20+3Подождите. Я чего-то не понимаю. Это такая ирония? Но сегодня не пятница по календарю. В чем инновационность? Где она вообще? Почти все сайты так работают.
Veikedo
07.09.2016 06:44+1Ага, что-то вообще не понял революционности. У нас, например, такой многостраничник на нокауте:
Автор, мы уже используем все преимущества вашего подхода?
nickorsk
07.09.2016 09:03-5Вообще не то.
Я скажу проще — у вас есть API, причем писали его не вы, а другая компания.
Нужно разработать приложение, которое будет работать через это API, оно мега сложное и имеет кучу страниц и логики.
Вы можете только UI интерфейс сделать на клиенте. Всякие CURL использовать не желательно, так как лучше чтобы нагрузка была в браузере через запросы напрямую к API.
Как вы сделаете его??
Суть статьи — что SPA не серебряная пуля и могут быть другие подходы к организации web приложения.webmasterx
07.09.2016 09:07+2Также как делали лет 8 назад. Когда была модная аббревиатура AJAX. раз уж нельзя SPA использовать
nickorsk
07.09.2016 09:23-4Так как это называлось?
Приложение по большей часте строилось на back-end и лишь некоторые части использовали AJAX.
И этот подход до сих пор использовался. Затем с ростом популярности мобильных приложений появился SPA, так как заказчики поняли, что писать приложение, а потом еще и API затратно и несет проблемы в поддержке.
И больше ничего не было придумано…webmasterx
07.09.2016 09:26Без понятия, есть ли у этого вообще название.
и подход до сих пор используется. и на сервере странички рендерят. и на клиенте. и часть на сервере, а часть на клиенте — это всем известные способы известные уже много лет.
Закзчики чаще всего не понимают что такое API, AJAX и т.д.nickorsk
07.09.2016 09:30-3Тут реализация ПОЛНОСТЬЮ через REST API и в этом вся суть.
То что частично работает через AJAX это не считается ;-)webmasterx
07.09.2016 09:38Считается. REST API не более чем стандартизация API. Не всегда разумно делать полностью API. Где было разумно — люди делали. Да, в далеком 2005.
nickorsk
07.09.2016 09:41Вот задача. Есть мобильные приложения, есть web приложение.
Как вы реализуете все это?
Будите писать отдельно web приложение и отдельно API?
Скорее всего выберите SPA. Альтернативы сегодня я не видел чтобы было где то описано, если вы видели просьба поделиться источниками.
AJAX или что то другое — это просто способ передачи данных. Есть другие способы. Это не архитектура веб приложения, а способ передачи данных.webmasterx
07.09.2016 09:45Можно написать и отдельно. Зависит от задач
Альтернативы нигде не написано потому, что альтернативы попросту очевидны.
lair
07.09.2016 12:09+1Я скажу проще — у вас есть API, причем писали его не вы, а другая компания.
Если "API писали не мы, а другая компания", то оно замкнуто, и запихнуть туда еще какой-то html сравнительно сложно. Не говоря о том, что оно легко может быть в отдельном контролируемом окружении.
Andrey_Volk
07.09.2016 06:58+11Какая то странная маленькая статья, которая существует по непонятным причинам.
VolCh
07.09.2016 07:49По сути предлагается несколько слабосвязанных SPA — грубо по одному на каждую коллекцию/корень агрегата? По-моему, минусов больше чем плюсов, если страницы плюс-минус имеют одинаковые раскладки, логику и т.п. Разве что совсем разные технологии используются.
claygod
07.09.2016 09:18По сути предлагается несколько слабосвязанных SPA
Что-то вроде дробления на фронт-микросервисы/презентеры?nickorsk
07.09.2016 09:47Не совсем.
SPA имеет MVC и роутеры и все похожее что было на back-end.
MVC хороша для организации всего приложения и оно остается на back-end.
Тут лучше строить все на компонентах. Та идея js фреймворков (Angular, Backbone и другие) тут мало годиться.
Логика упрощается и много будет лишнего.lair
07.09.2016 11:21MVC хороша для организации всего приложения и оно остается на back-end.
Вот только у вас на бэк-энде не MVC, а REST API. В котором MVC избыточен.
nickorsk
07.09.2016 11:35Объясняю.
REST API — содержит роутер(URL), контроллер, модель данных, а вьюха она используется только для тех запросов, которое возвращает статический html.
Еще раз html не содержит данных, не содержит никакой js логики. Всю логику интерфейса и обработку данных делают js компоненты или другие штуки, которые подключены к этой статической странице.
JS получают данные из той же API. И получается что API и веб приложение это одно и тоже.
lair
07.09.2016 11:40+2REST API — содержит роутер(URL), контроллер, модель данных, а вьюха она используется только для тех запросов, которое возвращает статический html.
Статический html не является частью REST API. Поэтому никого V в вашем мифическом серверном MVC нет. Без V это не presentation pattern.
Еще раз html не содержит данных, не содержит никакой js логики. Всю логику интерфейса и обработку данных делают js компоненты или другие штуки, которые подключены к этой статической странице.
И откуда же берутся эти компоненты? Материализуются магически, или все-таки передаются в рамках той же страницы с сервера?
nickorsk
07.09.2016 11:46-1Файлик не сложно же подключить?? :-)
А почему REST API не может html возвращать? Чем данные html отличаются от JSON например или XML??
Это просто данные.
Ресурсы конечно не являются частью REST API))lair
07.09.2016 12:01+1Файлик не сложно же подключить??
Не сложно. Но в этот момент ваше утверждение "html не содержит никакой js-логики" становится ложным.
А почему REST API не может html возвращать?
Потому что это противоречит концепции REST API.
nickorsk
07.09.2016 12:13Html же не содержит никакой логики. Это уже ресурсы страницы содержат, а это другое.
«Потому что это противоречит концепции REST API.» — это почему это??
REST API может возвращать все что угодно, JSON,HTML, Картинки, фидео, аудео — все что угодно.lair
07.09.2016 12:16+1Html же не содержит никакой логики. Это уже ресурсы страницы содержат, а это другое.
Это то же самое. Нет никакой разницы между тем, включили вы js-код в страницу напрямую или через
src.
это почему это??
Потому что вы нарушаете принцип единой ответственности. REST API отвечает за программное взаимодействие с системой, а HTML — это часть веб-приложения.
AnisimovAM
07.09.2016 08:32+5Напоминает ситуацию, когда начинающий разработчик сделал какое-то «мега крутое» открытие — придумал подход к разработке или архитекруту приложения (и он в это верит), а на самом деле просто не дочитал доки.
nickorsk
07.09.2016 08:57-3Ребята вот есть задача сделать API на котором работают несколько клиентов — это web, мобильные приложения и так далее.
На сегодняшний день описано только 2-ва подхода к разработке web приложений:
1. Мультистраничное приложение, когда интерфейс строиться на back-end.
2. SPA — когда логика клиента полностью на стороне клиента (за исключением одной страницы ). Использовать SPA подход на нескольких страницах это уже не SPA, а извращение.
3. Есть еще варианты? Тогда скажите название этого(их) подходов и их описание??
Так каким образом вы сделаете приложение так чтобы оно полностью базировалось на API??
Я имею в виду архитектурный подход, который имеет название, а не ваши абстракции.napa3um
07.09.2016 09:11+3Не всегда требуются названия. Вы как застёгиваете пуговицы на рубашке? Есть ли у этого способа название? Какие ещё существуют архитектурные паттерны для процесса застёгивания пуговиц? Вот и ваш newDHTML — это будто вы научились застёгивать пуговицы и решили дать этому название. Пуговицы придуманы для того, чтобы их продевали в петельки для удержания двух краёв одежды. И это не моё изобретение, это изначальное предназначение пуговиц. Но предлагаю назвать этот паттерн PugoFlow, чтобы отличать его от шнурования или застёгивания липучек.
nickorsk
07.09.2016 09:28-3Вот представьте — задача сделать приложение на REST API.
Один разработчик скажет «Я знаю способ, это способ SPA», а другой скажет «я знаю… а названия не могу сказать.»
Руководитель спросит, а как найти доку к нему, если оно даже названия не имеет??
Есть мультистраничное приложение (multipage application), которое идет еще с появления интернета и генераторов HTML (PHP например) и SPA.
Эти подходы имеют свое название, они описаны и про них можно прочитать.
Этот подход вообще родился на практике, и мне он понравился. Очень удобно.
Многие не прочитали даже до конца и не поняли сути, судя по комментариям. Так прочитайте и поймете идею от и до)
sentyaev
07.09.2016 09:40Вот представьте — задача сделать приложение на REST API.
Это скорее технические детали, а не задача.nickorsk
07.09.2016 09:49-2Вам ставит ее тимлид или вы сами понимаете что это оптимальный способ. НЕ важно.
Если вы решили так делать, то это уже задача.
Суть то не в том. Как вы это сделаете если вы решили так сделать?napa3um
07.09.2016 09:58Теперь придумайте, как будете решать задачу «нарисовать семь перпендикулярных линий». Не важно, сами вы это придумали, или вам такую задачу дал тимлид, если вы решили делать так, то это уже задача.
sl_bug
07.09.2016 10:02+1Легко :)
napa3um
07.09.2016 10:04Да, мне стоило придумать что-нибудь поабсурднее в своих доводах :).
nickorsk
07.09.2016 10:02Это бесполезный холивар)
Я написал какие аргументы есть, как это работает.
А в ответ вижу размышления про пуговицы, задачи или не задачи...))
sentyaev
07.09.2016 10:12+1Вы же решаете задачу заказчика. А у заказчика обычно задачи типа — просмотр товаров которые есть на складе, возможность скачать отчет и т.д.
Да и вам уже отвечали, то что вы описываете было популярно несколько лет назад, называлось AJAX и были написаны фреймворки для этого.
maxpsyhos
07.09.2016 10:25+1На сегодняшний день описано только 2-ва подхода к разработке web приложений
Вот в этом-то и проблема, что эти способы не взаимоисключающие, их можно комбинировать в любых пропорциях, следовательно их гораздо больше 2-х.
ggrnd0
07.09.2016 10:30Есть старый и надежный способ построения сложного webUI.
Названия не знаю. Но в нем как раз используется дробление приложения, на независимые страницы + AJAX (API).
Это не единственный подход, но он настолько прост и надежен, что до сих пор применяется в Enterprise и в потребительском сегменте...
ИнтригаДля этого используется <iframe/>
В index.html содержится некоторые общие элементы UI присущие приложению: шапка, футер, меню и прочее.Страница получается очень легкая, так как там минимум html/css/js.
Также на странице есть <iframe/>
Во время навигации по сайту, корневая страница остается неизменной.
Контент <iframe/> меняется при переходе по ссылкам или переходе в другой раздел сайта.
Каждая из страниц в <iframe/> может быть как статичной, так и динамичной.
А еще она может быть SPA и это не извращение, а реалии. SPA это не всегда подгрузка 2+мб минифицированного js кода. Они тоже бывают миниатюрные весом около 100кб (jQuery+код страницы).
Сам подход крайне популярен. Он используется:
- админка IBM WebSphere, Websense Triton: Secure Web gateway, Cisco IronPort
- админки домашних роутеров
- старый интерфейс vk
nickorsk
07.09.2016 10:33-1Вот!
Я тоже заметил что проще реализовать на разных страницах. Эти страницы статичные, на них динамичные части подгружаются js компонентами.
И это как раз настолько просто и надежно)
Вот это я и хотел донести)
Если есть название и описание подхода, то здорово. Я только за чтобы поднять тему)
lair
07.09.2016 12:16+1Так каким образом вы сделаете приложение так чтобы оно полностью базировалось на API??
Я имею в виду архитектурный подход, который имеет название"Тонкий клиент" это называется.
VolCh
08.09.2016 22:093. DHTML+AJAX — больше десятилетия уже в массах. По сути, SPA — это лишь вырожденный случай DHTML+AJAX приложения. Вы где были последние лет 10, что пропустили как зарождались SPA? )
KYuri
07.09.2016 10:00+3Автор, выкладывай todo-app, чтоб было видно, в чем новаторство подхода.
nickorsk
07.09.2016 10:12-1Для чего это все.
Во-первых, уже фактически стандарт если вы пишите приложение, то оно должно быть как минимум на мобильных устройствах. Сейчас очень много приложений пишутся по принципу «один сервер — много клиентов». Реализуется это как раз через REST API.
А чтобы написать web клиент есть только одна архитектура SPA. Она имеет название и описана.
Во-вторых, SPA имеет минусы и я их описал в статье. Кто не согласен с этим используйте SPA. Кому что нравиться.
Но что остается если вам не нравится SPA или может есть способы сделать проще и лучше?
Я повторюсь, это способ родился на практике. Я пишу приложения быстрее через этот способ чем SPA.
Каждая страница может работать самостоятельно, использовать разные технологии, не быть прибитым гвоздями к js фреймворку.
Вместо того чтобы спорить, предлагаю обсудить именно этот подход, как это работает и как можно улучшить подход.
Звучит как велосипед, но и SPA был когда то велосипедом и все было когда то — в начале.sentyaev
07.09.2016 10:34Я пишу приложения быстрее через этот способ чем SPA.
Это не совсем правильный аргумент.
Вот например я быстрее напишу приложение без тестов, с глобальными переменными, без разделения на слои и т.д.
И это нормально, если я пишу одноразовое, маленькое приложение, которое не нужно будет поддерживать и развивать.
Я могу предположить, что ваш подход оправдывает себя на ваших задачах. Но я также предполагаю, что с этим подходом вы решаете именно небольшие задачи.nickorsk
07.09.2016 10:44Может быть)
Тут дело вкуса. Я не пытаюсь очернить SPA, просто ничего идеального нет.
Можно строить приложения любой сложности на этой архитектуре. И я скажу что это проще монолитного SPA, если нет дайте аргументы.
Нет жесткой привязки к MVC фреймворку на fron-end. Тут не нужны страницы, не нужны роутеры и MVC по сути не особо то нужно.
Приложение MVC на front-end это монолит, по сути одно приложение, которое может сломаться если есть ошибка в каком то js файле. Поэтому SPA как правило жестко тестируется.
Back-end это просто API, которое кроме CRUD дополнительно отсылает статические html (просто html каркасы). Back-end тоже немного упрощается.
И вообще речь не обо мне.
Давайте обсудим аргументированно этот подход. Если что то было раньше — то я только за, но если это имеет документацию и есть примеры.
sentyaev
07.09.2016 11:46Тут дело вкуса.
Архитектура приложения не имеет отношения ко вкусу.
Приложение MVC на front-end это монолит
Вы неверно используете термин «монолит». Опять же из вики: In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.
А вообще, SPA не мешает вам писать модульное приложение, например в Angular2.
Как вы решаете следующие задачи:
0. Тестирование
1. Роутинг
2. Работу с формами (валидация например)
3. Темплейты
4. Работа с rest-api
5. Компоненты и их переиспользование
6. Работа с состоянием приложенияnickorsk
07.09.2016 12:07А могу я используя SPA использовать несколько фреймворков?
Вот Angular я выбрал и все роутеры только в нем, и все на нем завязано. Или вы сделаете 2 html страницы, на одной Angular, а на другой Backbone и каждый свои роутеры делает??
В том то дело что SPA это слишком монолитное приложение, перейти к другой технологии — значит переписывать все приложение. А это печально.
0. Пожалуйста пишите тесты какие вздумается.
1. Роутинг на стороне сервера.
2. Валидация через js компоненты на стороне клиента и на стороне сервера на уровне моделей. Все стандартно.
3. Темлейты на стороне клиента.
4. Через запросы на стороне клиента, например в js компоненте.
5. Можно подключать на разных страницах одинаковые компоненты. Если ООП то можно модифицировать. Все зависит от задач, повторное использование компонентов так же реально.
6. На стороне клиента.
sentyaev
07.09.2016 12:35А могу я используя SPA использовать несколько фреймворков?
Ну зачем усложнять приложение? Или вы не согласны с мнением, что чем меньше зависимостей тем лучше?
Вот используете вы например Angular, Angular2, React, Backbone и Ember с Aurelia в одном приложении, это же какой оверхед на поддержку будет. Да и разработчика найти с такими знаниями будет сложнее. А если у вас фича появится которая затронет несколько страниц, то придется в нескольких местах дублировать ее.
В том то дело что SPA это слишком монолитное приложение, перейти к другой технологии — значит переписывать все приложение.
Зачем менять технологию? Выберете фреймворк который будет жить лет 5 и пишите на нем.
Если у вас приложению жить недолго, можно и что-то новое попробовать, но если вы знаете, что приложение делается на века, то тут думать нужно стоит ли делать его на технологиях которые умрут через 3 месяца.
0. Пожалуйста пишите тесты какие вздумается.
В некоторых фреймворках это делается по разному.
1. Роутинг на стороне сервера.
Ну вот мы находимся на странице PageA, она у вас SPA (отдельное spa). У вас же есть роутинг в рамках этой страницы. Причем тут сервер. Получается у вас на каждую страницу своя библиотека роутинга?
А если переход на PageB, то как это сделать, window.location?
2. Валидация через js компоненты на стороне клиента и на стороне сервера на уровне моделей. Все стандартно.
Это слишком общий ответ. Я имел ввиду, что каждый фреймворк имеет поддержку валидации, и получается, что вы не сможете это переиспользовать.
3. Темлейты на стороне клиента.
Опять же, у каждого фреймворка свои темплейты, плюс есть куча темплейт библиотек, как потом этот зоопарк поддерживать?
4. Через запросы на стороне клиента, например в js компоненте.
Опять, на каждой странице будет своя библиотека.
5. Можно подключать на разных страницах одинаковые компоненты. Если ООП то можно модифицировать. Все зависит от задач, повторное использование компонентов так же реально.
Если на одной странице компонент написан на Angular2, а на другой у вас Knockout… Какое тут ООП.
6. На стороне клиента.
Опять, на одной странице у вас Flux, на другой Redux, на третьей просто глобальная переменная.
vlreshet
07.09.2016 10:03+3Хороший вы велосипед изобрели. Надёжный, удобный, устойчивый, быстро едет. На таких уже лет 10 как все катаются.
nickorsk
07.09.2016 10:13Все было когда то «велосипедом».
napa3um
07.09.2016 10:16+1Верно, и в данном случае «когда-то» — это в 2005-ом.
nickorsk
07.09.2016 10:26Опять про AJAX да?)))
ColdPhoenix
07.09.2016 10:55+1да хоть AJAX, хоть не AJAX.
смысл в том что вы динамически подгружаете контент, не важно как.
важен факт.
я подобный сайт писал лет 6 так назад, когда еще ничерта не знал.
сайт отлично работал и на JS, и при выключенном JS.
(+ еще History API и пользователь всегда мог взять URL и увидеть тоже самое)
тут нет никакого новаторства.
насчет AJAX, тогда не было иного толкового способа динамические запросы делать, потому и говорят про него.
ваш способ полностью аналогичен тому что был 10 лет назад, детали тут в нюансах.
тогда не было таких моднявых слов как REST API, тогда просто делали.nickorsk
07.09.2016 10:56«сайт отлично работал и на JS, и при выключенном JS» — значит это уже не то, о чем я писал.
vlreshet
07.09.2016 11:10AJAX — просто транспорт, и от того что его можно web-sockets — инновацией ваше решение не становится.
nickorsk
07.09.2016 11:18-1Вот я это и твержу уже тут раз 10!!!
AJAX это просто транспорт УРА!!))sentyaev
07.09.2016 11:24+1AJAX, Ajax (?e?d??ks, от англ. Asynchronous Javascript and XML — «асинхронный JavaScript и XML») — подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером.
Из википедии.
nickorsk
07.09.2016 11:27Больше и ничего.
А как это сделать. Все таки это подход к построению интерфейса, а не подход к построению приложения.
i360u
07.09.2016 10:20Почитайте про веб-компоненты и html-импорты. Ну и в списке минусов SPA согласиться с натяжкой можно только с 4-м пунктом, остальное — детский сад, уж простите.
nickorsk
07.09.2016 10:29-1Если устраивает SPA — то круто.
Статься не для критики SPA )i360u
07.09.2016 10:40+1Дело не в том, что устраивает, а в том, что строить решения на основе неверных предпосылок — есть инженерный фейл. И я утверждаю, что указанные предпосылки — неверны.
i360u
07.09.2016 10:43И я не зря написал про веб-компоненты, они позволяют комбинировать SPA c неSPA в вашем фронтэнде в любых пропорциях.
nickorsk
07.09.2016 10:46SPA — одностраничное приложение дословно. Все что имеет несколько страниц с сервера это уже не SPA.
Компоненты тут не причем. Есть либо одна страница с сервера(Тогда это SPA) или несколько, но это уже что то другое.napa3um
07.09.2016 10:54+2Не все аббревиатуры в ИТ (и, уверен, в других областях) несут смысл только лишь дословно содержащийся в буквах этой аббревиатуры. Не все технологии можно изучить лишь по их названию. Ограничение «если два SPA на одном адресе, то это уже не SPA» с практической стороны не несёт особого смысла, но может использоваться, наверное, в суде.
ColdPhoenix
07.09.2016 10:58извините, то есть для того чтоб быть SPA обязательно должен быть лишь один URL?
nickorsk
07.09.2016 11:02-1Должна быть одна страница html, на которую сажается js framework.
А клиент имитирует веб страницы через подгрузку шаблонов. На самое деле есть только одна страница и API и больше ничего. Это и есть Single page application.
i360u
07.09.2016 11:02SPA — одностраничное приложение дословно
да, SPA — это то, что позволяет работать с динамически обновляемыми данными без перезагрузки страницы-контейнера. Но страница !== приложение, строго говоря. Вы можете на сгенерированной сервером странице иметь виджет со своей сложной внутренней логикой, влияющей на свое окружение. Вы можете перегружать такие страницы отдельно от этого виждета и это будет комбинированным подходом. Вы можете воспринимать сгенерированный html как данные, либо как контейнер для вашего SPA, в соответсвии с вашими задачами, разбивая все приложение на разделы и модули как вам угодно. И компоненты — это то, что позволяет все это делать с легкостью, они еще как причем.
nickorsk
07.09.2016 11:08Всем понятно что такое SPA. Можно что то по своему делать, да.
Суть проблемы что есть API и как нам сделать веб приложение через это API.
Это можно через SPA сделать, но можно и не через SPA.
И не понимаю что на меня так набросились. Я же не говорю что SPA это плохо, а предложил вариант как можно написать приложение на API без использования SPA, MVC и прочих штук на front-end.
i360u
07.09.2016 11:28Без каких прочих штук? Вы сами пишите, что js, в предложеной вами архитектуре, работает с динамическими данными: "вся динамическая часть собирается javascript-ом на стороне клиента". Как это магическим образом исключает SPA, MVC и "прочие штуки"? А раздавать прочую статику сервера умеют давно, как это относится к вашей идее? Ваш API может возвращать что угодно, и голые данные и сврстанные, для чего есть куча устоявшихся методов, на что именно из этой экосистемы вы вглянули по новому?
nickorsk
07.09.2016 11:38Во-первых. Тут многоcтраничность и это не SPA.
Во-вторых, все работает через API.i360u
07.09.2016 12:44Вы изобрели многостраничность и "не-SPA"? Или вы изобрели API? Или вы просто издеваетесь? Вот знаете, я могу допустить, что в ваших идеях, возможно, есть какое-то рациональное зерно, возможно просто вы не можете подобрать правильные слова для их описания, но на данный момент, выглядит все это более чем сомнительно, мягко говоря.
napa3um
07.09.2016 11:32Набросились на вас за резонёрство, за попытку создания альтернативной терминологии без практической на то необходимости, за выдумывание теоретических проблем, не существующих на практике.
habradante
07.09.2016 10:49+2Непонимаю. Автор взял API реализовал для него клиента на HTML и назвал это новым подходом? Статичные шаблоны возвращаются по запросу с сервера API, а не с сервера клиента. Таким образом смешали логику и шаблоны клиента, что вообще не очень хорошо. Раз уж делаете API, то вынесите его на один адрес, а шаблоны, скрипты и стили клиента на другой. Тут, по-моему, не новый подход к разработке, а нарушение уже устоявшихся.
API для того и существует чтобы предоставлять данные для ЛЮБОГО интерфейса, и HTML-клиент лишь один из нескольких возможных. Если появятся для этого API клиенты на iOS или Android, то им тоже надо знать где лежат шаблоны books-index?nickorsk
07.09.2016 10:50«смешали логику и шаблоны клиента» — нету никакой логики шаблонов.
По сути и шаблонизаторы на сервере не нужны, потому что там шаблонов нет. Возвращается каркас html без данных вообще.
Максимум можно комбинировать кусок с header и footer и статичный кусок страницы, это можно даже include обычным сделать.
Больше логики html никакой на back-end нету.ColdPhoenix
07.09.2016 11:07шаблоны еще клиентские бывают )
nickorsk
07.09.2016 11:11Ага. И вот тут к нам приходят уже заранее подключенные на статическую страницу js компоненты или другие штуки которые вам нравятся.
Они то всю динамику и логику интерфейса и делают.
То есть можно сделать компонент, шаблонизатор для него и в перед. И страница будет вообще работать как отдельное приложение. Каждая страница сервиса!
nickorsk
07.09.2016 11:22«Если появятся для этого API клиенты на iOS или Android, то им тоже надо знать где лежат шаблоны books-index?» — нет, суть в том что само веб приложение есть API.
Проще говоря, почему мы не можем html через API слать, но html этот не содержит логики, это просто кусок html — меню, header, footer и прочие вещи которые не меняются.
На эту же страницу ставятся js компоненты или другие штуки, они то всю динамику и логику интерфейса и делают.
А для мобильников все так же, просто они не используют запросы которые возвращают html статику :-)
Вот и все.habradante
07.09.2016 11:45Суть как раз в том, что API не должно быть веб-приложением. Оно само по себе, это просто интерфейс для доступа к данным.
«Проще говоря, почему мы не можем html через API слать, но html этот не содержит логики, это просто кусок html — меню, header, footer и прочие вещи которые не меняются.»
Можете, но это уже не API. Вы просто выдаете клиентские шаблоны для страниц.
«А для мобильников все так же, просто они не используют запросы которые возвращают html статику :-)»
Вы просто смешали чати приложения и API вместе, а потом говорите программисту «используй только эту часть, это true-API, а это чать веб-приложения». А потом вам понадобится дать доступ к API другим программистам, чтобы они на его основе сделали свое мобильное приложение и вы им выдадите вот это все. Они, конечно же, зададут вам вопросы «нафига нам html странички?», на что вы им скажете что это торчат части другого клиента и им их использовать не надо.
Пройдет время, вы захотите поменять свои веб-странички выдаваемые API и… в этот момент в комнату влетает разгневанный начальник/клиент/заказчик и кричит «верни все назад, у команды из Индии/Китая/Другой страны все рухнуло, это ты виноват!». И знаете, он будет прав, потому что кто-то из той команды программистов заиспользовал ваши html-шаблоны и теперь вы с ними связаны и не можете обновить ваш сайт.
А еще спустя какое-то время, вас попросят выкатить новую версию API, с немного другими шаблонами. И, вуа-ля, у вас уже три версии html-страничек: для старого API, нового API и вашего нового сайта.nickorsk
07.09.2016 11:56-2Такс. Окей.
А зачем мобильникам эти страницы ?)
Не используют и что. Даже если в страницах что то поменяется от этого ничего не измениться.
«Пройдет время, вы захотите поменять свои веб-странички выдаваемые API» — эти страницы часть веб клиента, в чем проблема если они поменяются?)
Но Бог с ним. Допустим мы вынесем из API html страницы.
Самое главное что веб приложение будет так же работать через REST API.
habradante
07.09.2016 12:40«А зачем мобильникам эти страницы ?) „
Да мало ли что взбредет в голову программистам, которым вы дадите это API. Может захотят сделать какие-то страницы внутри приложения на html.
Если в страницах (а это воспринимается как часть API) что-то изменится, то формально поменяется API.
“Самое главное что веб приложение будет так же работать через REST API.»
Вот об этом вам и говорят, что у вас просто веб-приложение работает через REST API, это не новый подход. Он давно практикуется в случаях, когда нужно чтобы на выходе и API было и приложение. И чтобы не писать для приложения отдельный back-end, его просто заменяют на API. А дальше, как правило, MVC-фреймворк на клиенте.
Сама разработка в таком случае строится на том, что параллельно с клиентской частью на html пишется API, которое просто выдает данные ничего не зная о специфике клиента. На стороне браузера, как правило, SPA, который просто с сервера подтягивает статичные шаблоны страниц и манипулирует ими. Вообще как устроен клиент, в данном случае не столь важно, т.к. к REST API можно прикрутить что угодно. Важно лишь то, что клиент отдельно, API отдельно.
Riim
07.09.2016 12:37А затем вдруг часть состояния с одной страницы нужно передать на другую и начинается гемор с сохранением его куда-то и дальнейшим восстановлением. Через какое-то время приложение становиться достаточно сложным и гемор с постоянным сохранением/восстановлением начинает перекрывать все другие плюсы. Выкидываем всё сделанное, пишем нормальное SPA.
Riim
07.09.2016 12:46+1И самое весёлое, когда часть сохраняемого состояния нужно генерить на сервере, а другую часть восстанавливать на клиенте. Что-то запихиваем в url, что-то в localStorage, ваще ништяк получается))
lair
А зачем вообще REST API в этом случае?
napa3um
Заметил, что фраза «работает на API» вошла в число аргументов для заказчика в пользу качества сайта. Что-то типа приставки «нано-» или «нейро-».
nickorsk
Еще раз.
REST API и веб приложение одно и то же, это основная идея.
Просто есть специальные GET запросы, которые возвращают статический html(это просто каркас из html и подключенных js/css файлов).
Динамические куски html собираются через запросы к этому жe API.
Запросы отсылают js компоненты, они же рендерят из полученных данных куски html и вставляют их в нужный контейнер.
В итоге пользователь видит готовую страницу с данными.
Вот и весь подход, если что то не понятно — задавайте вопросы )
napa3um
Так делали (и делают) сайты до «изобретения» SPA, фичу динамической погрузки контента называли новомодным словом AJAX, и это было прорывом по сравненению с изначальным способом построения страниц полностью на сервере. Вы сделали революционное открытие 2005-го года.
nickorsk
Я же говорю — полностью базируется на REST API.
B более того web приложение это и есть REST API. Если где то было описано в 2005 году, именно такой способ организации целого приложения, то ссылочку я почитаю)
AJAX это не имеет особого отношения к этому, можно и через web socket API сделать то же самое))
Но web socket мы тоже не затрагиваем.
Потому что это все просто способы передачи данных и не более.
RouR
Без примера кода сложно понять что именно предлагаете
nickorsk
В следующей части и попробуем сделать.
Но для начала хорошо понять, примерно как архитектура эта работает))
fetis26
Написано слишком мало для статьи. Скорее тезис какой-то невнятный
lair
И это плохая идея. У REST API общего назначения и у веб-приложения может быть много различий (вплоть до разных технологий). Зачем смешивать их в одну кучу?
Если мне нужно веб-приложение — я могу написать просто веб-приложение, зачем мне еще REST API городить? Если мне нужно REST API кроме как для веб-приложения — зачем мне их связывать?