SPA — не серебряная пуля, или альтернативный подход к web-разработке. Часть 1

Цель паблика не раскритиковать подход SPA, а показать какие есть альтернативы для реализации web приложения, основанного на API. Прошу обсуждать только сам подход, его минусы и плюсы.

Я придумал название для данного архитектурного стиля — 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 — максимум поломается только одна страница из множества.
  • Ну и другие плюсы, если заметите пишите.

Во второй части планирую написать про компоненты. А пока всем спасибо за внимание и удачи!
Идея и текст автора.

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 116

    0

    А зачем вообще REST API в этом случае?

      0
      Заметил, что фраза «работает на API» вошла в число аргументов для заказчика в пользу качества сайта. Что-то типа приставки «нано-» или «нейро-».
        0
        Еще раз.
        REST API и веб приложение одно и то же, это основная идея.
        Просто есть специальные GET запросы, которые возвращают статический html(это просто каркас из html и подключенных js/css файлов).
        Динамические куски html собираются через запросы к этому жe API.
        Запросы отсылают js компоненты, они же рендерят из полученных данных куски html и вставляют их в нужный контейнер.
        В итоге пользователь видит готовую страницу с данными.

        Вот и весь подход, если что то не понятно — задавайте вопросы )
          +6
          Так делали (и делают) сайты до «изобретения» SPA, фичу динамической погрузки контента называли новомодным словом AJAX, и это было прорывом по сравненению с изначальным способом построения страниц полностью на сервере. Вы сделали революционное открытие 2005-го года.
            0
            Я же говорю — полностью базируется на REST API.
            B более того web приложение это и есть REST API. Если где то было описано в 2005 году, именно такой способ организации целого приложения, то ссылочку я почитаю)

            AJAX это не имеет особого отношения к этому, можно и через web socket API сделать то же самое))
            Но web socket мы тоже не затрагиваем.
            Потому что это все просто способы передачи данных и не более.
              0
              Без примера кода сложно понять что именно предлагаете
                –4
                В следующей части и попробуем сделать.
                Но для начала хорошо понять, примерно как архитектура эта работает))
                  +2

                  Написано слишком мало для статьи. Скорее тезис какой-то невнятный

            0
            REST API и веб приложение одно и то же, это основная идея.

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


            Если мне нужно веб-приложение — я могу написать просто веб-приложение, зачем мне еще REST API городить? Если мне нужно REST API кроме как для веб-приложения — зачем мне их связывать?

          +4
          Вы придумали «архитектуру», на которой уже базируется ~90% сайтов всего видимого интернета (т.е., «нехипстерская» его доля), и к которой толкает PHP «by design» (особенно без MVC-фреймворков, когда роутер — это файловая система и иногда плагин mod_rewrite).
            –3
            Может и не я это придумал))
            Эта архитектура зародилась в работе и не только моей.
            +1
            Ваша идея очень похожа на rails-turbolinks gem.
            На самом деле идея SPA растет из одной большой идеи — держать общее API для взаимодействия нескольких платформ, например одно и тоже API может использоваться SPA, iOS App, Android App и иметь какой-нибудь SOAP-фасад для Delphi или других интеграций.
            Если вы почитаете описания многих фреймворков, то обратите внимание на их модульность и возможность комбинирования компонентов. Совсем не обязательно создавать одно большое SPA, иногда его можно разделить на несколько более мелких частей.
              –1
              Да SPA именно для этого создавалась. НО это единственный подход для построения приложения, базирующегося на API?

              Если на нескольких страницах использовать «SPA» — это уже не SPA, так как это уже не одностраничное приложение( Single Page Application)
              +3
              Подождите. Я чего-то не понимаю. Это такая ирония? Но сегодня не пятница по календарю. В чем инновационность? Где она вообще? Почти все сайты так работают.
                +1

                Ага, что-то вообще не понял революционности. У нас, например, такой многостраничник на нокауте:
                image


                Автор, мы уже используем все преимущества вашего подхода?

                  –5
                  Вообще не то.
                  Я скажу проще — у вас есть API, причем писали его не вы, а другая компания.
                  Нужно разработать приложение, которое будет работать через это API, оно мега сложное и имеет кучу страниц и логики.
                  Вы можете только UI интерфейс сделать на клиенте. Всякие CURL использовать не желательно, так как лучше чтобы нагрузка была в браузере через запросы напрямую к API.
                  Как вы сделаете его??

                  Суть статьи — что SPA не серебряная пуля и могут быть другие подходы к организации web приложения.
                    +2
                    Также как делали лет 8 назад. Когда была модная аббревиатура AJAX. раз уж нельзя SPA использовать
                      –4
                      Так как это называлось?
                      Приложение по большей часте строилось на back-end и лишь некоторые части использовали AJAX.
                      И этот подход до сих пор использовался. Затем с ростом популярности мобильных приложений появился SPA, так как заказчики поняли, что писать приложение, а потом еще и API затратно и несет проблемы в поддержке.

                      И больше ничего не было придумано…
                        0
                        Без понятия, есть ли у этого вообще название.
                        и подход до сих пор используется. и на сервере странички рендерят. и на клиенте. и часть на сервере, а часть на клиенте — это всем известные способы известные уже много лет.
                        Закзчики чаще всего не понимают что такое API, AJAX и т.д.
                          –3
                          Тут реализация ПОЛНОСТЬЮ через REST API и в этом вся суть.

                          То что частично работает через AJAX это не считается ;-)
                            0
                            Считается. REST API не более чем стандартизация API. Не всегда разумно делать полностью API. Где было разумно — люди делали. Да, в далеком 2005.
                              0
                              Вот задача. Есть мобильные приложения, есть web приложение.
                              Как вы реализуете все это?

                              Будите писать отдельно web приложение и отдельно API?
                              Скорее всего выберите SPA. Альтернативы сегодня я не видел чтобы было где то описано, если вы видели просьба поделиться источниками.

                              AJAX или что то другое — это просто способ передачи данных. Есть другие способы. Это не архитектура веб приложения, а способ передачи данных.
                                0
                                Можно написать и отдельно. Зависит от задач
                                Альтернативы нигде не написано потому, что альтернативы попросту очевидны.
                                  0
                                  И как бы вы сделали?
                                    0
                                    Зависит от задач
                      +1
                      Я скажу проще — у вас есть API, причем писали его не вы, а другая компания.

                      Если "API писали не мы, а другая компания", то оно замкнуто, и запихнуть туда еще какой-то html сравнительно сложно. Не говоря о том, что оно легко может быть в отдельном контролируемом окружении.

                    • НЛО прилетело и опубликовало эту надпись здесь
                        0

                        notepad++ обычный

                    +11
                    Какая то странная маленькая статья, которая существует по непонятным причинам.
                      0
                      По сути предлагается несколько слабосвязанных SPA — грубо по одному на каждую коллекцию/корень агрегата? По-моему, минусов больше чем плюсов, если страницы плюс-минус имеют одинаковые раскладки, логику и т.п. Разве что совсем разные технологии используются.
                        0
                        По сути предлагается несколько слабосвязанных SPA

                        Что-то вроде дробления на фронт-микросервисы/презентеры?
                          0
                          Не совсем.

                          SPA имеет MVC и роутеры и все похожее что было на back-end.
                          MVC хороша для организации всего приложения и оно остается на back-end.
                          Тут лучше строить все на компонентах. Та идея js фреймворков (Angular, Backbone и другие) тут мало годиться.
                          Логика упрощается и много будет лишнего.
                            0
                            MVC хороша для организации всего приложения и оно остается на back-end.

                            Вот только у вас на бэк-энде не MVC, а REST API. В котором MVC избыточен.

                              0
                              Объясняю.
                              REST API — содержит роутер(URL), контроллер, модель данных, а вьюха она используется только для тех запросов, которое возвращает статический html.

                              Еще раз html не содержит данных, не содержит никакой js логики. Всю логику интерфейса и обработку данных делают js компоненты или другие штуки, которые подключены к этой статической странице.

                              JS получают данные из той же API. И получается что API и веб приложение это одно и тоже.

                                +2
                                REST API — содержит роутер(URL), контроллер, модель данных, а вьюха она используется только для тех запросов, которое возвращает статический html.

                                Статический html не является частью REST API. Поэтому никого V в вашем мифическом серверном MVC нет. Без V это не presentation pattern.


                                Еще раз html не содержит данных, не содержит никакой js логики. Всю логику интерфейса и обработку данных делают js компоненты или другие штуки, которые подключены к этой статической странице.

                                И откуда же берутся эти компоненты? Материализуются магически, или все-таки передаются в рамках той же страницы с сервера?

                                  –1
                                  Файлик не сложно же подключить?? :-)
                                  А почему REST API не может html возвращать? Чем данные html отличаются от JSON например или XML??
                                  Это просто данные.

                                  Ресурсы конечно не являются частью REST API))
                                    +1
                                    Файлик не сложно же подключить??

                                    Не сложно. Но в этот момент ваше утверждение "html не содержит никакой js-логики" становится ложным.


                                    А почему REST API не может html возвращать?

                                    Потому что это противоречит концепции REST API.

                                      0
                                      Html же не содержит никакой логики. Это уже ресурсы страницы содержат, а это другое.

                                      «Потому что это противоречит концепции REST API.» — это почему это??

                                      REST API может возвращать все что угодно, JSON,HTML, Картинки, фидео, аудео — все что угодно.
                                        +1
                                        Html же не содержит никакой логики. Это уже ресурсы страницы содержат, а это другое.

                                        Это то же самое. Нет никакой разницы между тем, включили вы js-код в страницу напрямую или через src.


                                        это почему это??

                                        Потому что вы нарушаете принцип единой ответственности. REST API отвечает за программное взаимодействие с системой, а HTML — это часть веб-приложения.

                                      0
                                      .
                          +5
                          Напоминает ситуацию, когда начинающий разработчик сделал какое-то «мега крутое» открытие — придумал подход к разработке или архитекруту приложения (и он в это верит), а на самом деле просто не дочитал доки.
                            0
                            Введение к статье я вижу, а где она сама-то?
                              –3
                              Ребята вот есть задача сделать API на котором работают несколько клиентов — это web, мобильные приложения и так далее.

                              На сегодняшний день описано только 2-ва подхода к разработке web приложений:
                              1. Мультистраничное приложение, когда интерфейс строиться на back-end.
                              2. SPA — когда логика клиента полностью на стороне клиента (за исключением одной страницы ). Использовать SPA подход на нескольких страницах это уже не SPA, а извращение.
                              3. Есть еще варианты? Тогда скажите название этого(их) подходов и их описание??

                              Так каким образом вы сделаете приложение так чтобы оно полностью базировалось на API??
                              Я имею в виду архитектурный подход, который имеет название, а не ваши абстракции.
                                +3
                                Не всегда требуются названия. Вы как застёгиваете пуговицы на рубашке? Есть ли у этого способа название? Какие ещё существуют архитектурные паттерны для процесса застёгивания пуговиц? Вот и ваш newDHTML — это будто вы научились застёгивать пуговицы и решили дать этому название. Пуговицы придуманы для того, чтобы их продевали в петельки для удержания двух краёв одежды. И это не моё изобретение, это изначальное предназначение пуговиц. Но предлагаю назвать этот паттерн PugoFlow, чтобы отличать его от шнурования или застёгивания липучек.
                                  –3
                                  Вот представьте — задача сделать приложение на REST API.

                                  Один разработчик скажет «Я знаю способ, это способ SPA», а другой скажет «я знаю… а названия не могу сказать.»
                                  Руководитель спросит, а как найти доку к нему, если оно даже названия не имеет??

                                  Есть мультистраничное приложение (multipage application), которое идет еще с появления интернета и генераторов HTML (PHP например) и SPA.
                                  Эти подходы имеют свое название, они описаны и про них можно прочитать.

                                  Этот подход вообще родился на практике, и мне он понравился. Очень удобно.

                                  Многие не прочитали даже до конца и не поняли сути, судя по комментариям. Так прочитайте и поймете идею от и до)
                                    0
                                    Вот представьте — задача сделать приложение на REST API.

                                    Это скорее технические детали, а не задача.
                                      –2
                                      Вам ставит ее тимлид или вы сами понимаете что это оптимальный способ. НЕ важно.
                                      Если вы решили так делать, то это уже задача.

                                      Суть то не в том. Как вы это сделаете если вы решили так сделать?
                                        0
                                        Теперь придумайте, как будете решать задачу «нарисовать семь перпендикулярных линий». Не важно, сами вы это придумали, или вам такую задачу дал тимлид, если вы решили делать так, то это уже задача.
                                          +1
                                          Легко :)
                                          image

                                            0
                                            Да, мне стоило придумать что-нибудь поабсурднее в своих доводах :).
                                              0
                                              Стоило лишь добавить «взаимно перпендикулярных» :)
                                                +2
                                                Ок
                                                image
                                                  0
                                                  О боги, я и представить такое не мог! :D
                                            0
                                            Это бесполезный холивар)

                                            Я написал какие аргументы есть, как это работает.
                                            А в ответ вижу размышления про пуговицы, задачи или не задачи...))
                                            +1
                                            Вы же решаете задачу заказчика. А у заказчика обычно задачи типа — просмотр товаров которые есть на складе, возможность скачать отчет и т.д.

                                            Да и вам уже отвечали, то что вы описываете было популярно несколько лет назад, называлось AJAX и были написаны фреймворки для этого.
                                      +1
                                      На сегодняшний день описано только 2-ва подхода к разработке web приложений


                                      Вот в этом-то и проблема, что эти способы не взаимоисключающие, их можно комбинировать в любых пропорциях, следовательно их гораздо больше 2-х.

                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          –1
                                          Вот!
                                          Я тоже заметил что проще реализовать на разных страницах. Эти страницы статичные, на них динамичные части подгружаются js компонентами.
                                          И это как раз настолько просто и надежно)
                                          Вот это я и хотел донести)
                                          Если есть название и описание подхода, то здорово. Я только за чтобы поднять тему)
                                          +1
                                          Так каким образом вы сделаете приложение так чтобы оно полностью базировалось на API??
                                          Я имею в виду архитектурный подход, который имеет название

                                          "Тонкий клиент" это называется.

                                            0
                                            3. DHTML+AJAX — больше десятилетия уже в массах. По сути, SPA — это лишь вырожденный случай DHTML+AJAX приложения. Вы где были последние лет 10, что пропустили как зарождались SPA? )
                                            +3
                                            Автор, выкладывай todo-app, чтоб было видно, в чем новаторство подхода.
                                              –1
                                              Для чего это все.

                                              Во-первых, уже фактически стандарт если вы пишите приложение, то оно должно быть как минимум на мобильных устройствах. Сейчас очень много приложений пишутся по принципу «один сервер — много клиентов». Реализуется это как раз через REST API.
                                              А чтобы написать web клиент есть только одна архитектура SPA. Она имеет название и описана.

                                              Во-вторых, SPA имеет минусы и я их описал в статье. Кто не согласен с этим используйте SPA. Кому что нравиться.

                                              Но что остается если вам не нравится SPA или может есть способы сделать проще и лучше?

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

                                              Вместо того чтобы спорить, предлагаю обсудить именно этот подход, как это работает и как можно улучшить подход.

                                              Звучит как велосипед, но и SPA был когда то велосипедом и все было когда то — в начале.
                                                0
                                                Я пишу приложения быстрее через этот способ чем SPA.

                                                Это не совсем правильный аргумент.

                                                Вот например я быстрее напишу приложение без тестов, с глобальными переменными, без разделения на слои и т.д.

                                                И это нормально, если я пишу одноразовое, маленькое приложение, которое не нужно будет поддерживать и развивать.

                                                Я могу предположить, что ваш подход оправдывает себя на ваших задачах. Но я также предполагаю, что с этим подходом вы решаете именно небольшие задачи.
                                                  0
                                                  Может быть)
                                                  Тут дело вкуса. Я не пытаюсь очернить SPA, просто ничего идеального нет.
                                                  Можно строить приложения любой сложности на этой архитектуре. И я скажу что это проще монолитного SPA, если нет дайте аргументы.

                                                  Нет жесткой привязки к MVC фреймворку на fron-end. Тут не нужны страницы, не нужны роутеры и MVC по сути не особо то нужно.
                                                  Приложение MVC на front-end это монолит, по сути одно приложение, которое может сломаться если есть ошибка в каком то js файле. Поэтому SPA как правило жестко тестируется.

                                                  Back-end это просто API, которое кроме CRUD дополнительно отсылает статические html (просто html каркасы). Back-end тоже немного упрощается.

                                                  И вообще речь не обо мне.

                                                  Давайте обсудим аргументированно этот подход. Если что то было раньше — то я только за, но если это имеет документацию и есть примеры.

                                                    0
                                                    Тут дело вкуса.

                                                    Архитектура приложения не имеет отношения ко вкусу.

                                                    Приложение 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. Работа с состоянием приложения
                                                      0
                                                      А могу я используя SPA использовать несколько фреймворков?

                                                      Вот Angular я выбрал и все роутеры только в нем, и все на нем завязано. Или вы сделаете 2 html страницы, на одной Angular, а на другой Backbone и каждый свои роутеры делает??
                                                      В том то дело что SPA это слишком монолитное приложение, перейти к другой технологии — значит переписывать все приложение. А это печально.

                                                      0. Пожалуйста пишите тесты какие вздумается.
                                                      1. Роутинг на стороне сервера.
                                                      2. Валидация через js компоненты на стороне клиента и на стороне сервера на уровне моделей. Все стандартно.
                                                      3. Темлейты на стороне клиента.
                                                      4. Через запросы на стороне клиента, например в js компоненте.
                                                      5. Можно подключать на разных страницах одинаковые компоненты. Если ООП то можно модифицировать. Все зависит от задач, повторное использование компонентов так же реально.
                                                      6. На стороне клиента.

                                                        0
                                                        А могу я используя 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, на третьей просто глобальная переменная.
                                              +3
                                              Хороший вы велосипед изобрели. Надёжный, удобный, устойчивый, быстро едет. На таких уже лет 10 как все катаются.
                                                0
                                                Все было когда то «велосипедом».
                                                  +1
                                                  Верно, и в данном случае «когда-то» — это в 2005-ом.
                                                    0
                                                    Опять про AJAX да?)))
                                                      +1
                                                      Про newDHTML, если вам так больше нравится.
                                                        +1
                                                        да хоть AJAX, хоть не AJAX.
                                                        смысл в том что вы динамически подгружаете контент, не важно как.
                                                        важен факт.
                                                        я подобный сайт писал лет 6 так назад, когда еще ничерта не знал.
                                                        сайт отлично работал и на JS, и при выключенном JS.
                                                        (+ еще History API и пользователь всегда мог взять URL и увидеть тоже самое)

                                                        тут нет никакого новаторства.

                                                        насчет AJAX, тогда не было иного толкового способа динамические запросы делать, потому и говорят про него.

                                                        ваш способ полностью аналогичен тому что был 10 лет назад, детали тут в нюансах.
                                                        тогда не было таких моднявых слов как REST API, тогда просто делали.
                                                          0
                                                          «сайт отлично работал и на JS, и при выключенном JS» — значит это уже не то, о чем я писал.
                                                            +1
                                                            в современном мире это называется fallback.
                                                              –1
                                                              может, но не наш случай.
                                                          0
                                                          AJAX — просто транспорт, и от того что его можно web-sockets — инновацией ваше решение не становится.
                                                            –1
                                                            Вот я это и твержу уже тут раз 10!!!
                                                            AJAX это просто транспорт УРА!!))
                                                              +1
                                                              AJAX, Ajax (ˈeɪdʒæks, от англ. Asynchronous Javascript and XML — «асинхронный JavaScript и XML») — подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером.

                                                              Из википедии.
                                                                0
                                                                Больше и ничего.
                                                                А как это сделать. Все таки это подход к построению интерфейса, а не подход к построению приложения.
                                                                  +2
                                                                  Я лишь сказал, что AJAX — не транспорт.

                                                                  Вы уже не в первый раз используете не верную терминологию. Это не способствует пониманию вашей идеи.
                                                                    –1
                                                                    Это не имеет отношения к теме. Просто холивар об AJAX :-)
                                                    0

                                                    Почитайте про веб-компоненты и html-импорты. Ну и в списке минусов SPA согласиться с натяжкой можно только с 4-м пунктом, остальное — детский сад, уж простите.

                                                      0
                                                      4 пункт тоже решаем. Есть же serverside rendering.
                                                        0

                                                        Ну поэтому и говорю "с натяжкой", то есть решаемо но необходимы некие телодвижения.

                                                        –1
                                                        Если устраивает SPA — то круто.
                                                        Статься не для критики SPA )
                                                          +1

                                                          Дело не в том, что устраивает, а в том, что строить решения на основе неверных предпосылок — есть инженерный фейл. И я утверждаю, что указанные предпосылки — неверны.

                                                            0

                                                            И я не зря написал про веб-компоненты, они позволяют комбинировать SPA c неSPA в вашем фронтэнде в любых пропорциях.

                                                              0
                                                              SPA — одностраничное приложение дословно. Все что имеет несколько страниц с сервера это уже не SPA.

                                                              Компоненты тут не причем. Есть либо одна страница с сервера(Тогда это SPA) или несколько, но это уже что то другое.
                                                                +2
                                                                Не все аббревиатуры в ИТ (и, уверен, в других областях) несут смысл только лишь дословно содержащийся в буквах этой аббревиатуры. Не все технологии можно изучить лишь по их названию. Ограничение «если два SPA на одном адресе, то это уже не SPA» с практической стороны не несёт особого смысла, но может использоваться, наверное, в суде.
                                                                  0
                                                                  извините, то есть для того чтоб быть SPA обязательно должен быть лишь один URL?
                                                                    –1
                                                                    Должна быть одна страница html, на которую сажается js framework.
                                                                    А клиент имитирует веб страницы через подгрузку шаблонов. На самое деле есть только одна страница и API и больше ничего. Это и есть Single page application.
                                                                    0
                                                                    SPA — одностраничное приложение дословно

                                                                    да, SPA — это то, что позволяет работать с динамически обновляемыми данными без перезагрузки страницы-контейнера. Но страница !== приложение, строго говоря. Вы можете на сгенерированной сервером странице иметь виджет со своей сложной внутренней логикой, влияющей на свое окружение. Вы можете перегружать такие страницы отдельно от этого виждета и это будет комбинированным подходом. Вы можете воспринимать сгенерированный html как данные, либо как контейнер для вашего SPA, в соответсвии с вашими задачами, разбивая все приложение на разделы и модули как вам угодно. И компоненты — это то, что позволяет все это делать с легкостью, они еще как причем.

                                                                      0
                                                                      Всем понятно что такое SPA. Можно что то по своему делать, да.

                                                                      Суть проблемы что есть API и как нам сделать веб приложение через это API.

                                                                      Это можно через SPA сделать, но можно и не через SPA.

                                                                      И не понимаю что на меня так набросились. Я же не говорю что SPA это плохо, а предложил вариант как можно написать приложение на API без использования SPA, MVC и прочих штук на front-end.


                                                                        0

                                                                        Без каких прочих штук? Вы сами пишите, что js, в предложеной вами архитектуре, работает с динамическими данными: "вся динамическая часть собирается javascript-ом на стороне клиента". Как это магическим образом исключает SPA, MVC и "прочие штуки"? А раздавать прочую статику сервера умеют давно, как это относится к вашей идее? Ваш API может возвращать что угодно, и голые данные и сврстанные, для чего есть куча устоявшихся методов, на что именно из этой экосистемы вы вглянули по новому?

                                                                          0
                                                                          Во-первых. Тут многоcтраничность и это не SPA.
                                                                          Во-вторых, все работает через API.
                                                                            0

                                                                            Вы изобрели многостраничность и "не-SPA"? Или вы изобрели API? Или вы просто издеваетесь? Вот знаете, я могу допустить, что в ваших идеях, возможно, есть какое-то рациональное зерно, возможно просто вы не можете подобрать правильные слова для их описания, но на данный момент, выглядит все это более чем сомнительно, мягко говоря.

                                                                          0
                                                                          Набросились на вас за резонёрство, за попытку создания альтернативной терминологии без практической на то необходимости, за выдумывание теоретических проблем, не существующих на практике.
                                                                            0
                                                                            Я ничего не создавал, я только описал то что было на практитке и мне понравилось.
                                                                              +1
                                                                              Вас ждет, похоже, ещё множество открытий, но не всеми стОит делиться с широким кругом читателей. Даже для Хабра низковат уровень подобных описаний.
                                                                                0
                                                                                Вот правда, что вы тут развели, дайте человеку время опыта набраться.
                                                                +2
                                                                Непонимаю. Автор взял API реализовал для него клиента на HTML и назвал это новым подходом? Статичные шаблоны возвращаются по запросу с сервера API, а не с сервера клиента. Таким образом смешали логику и шаблоны клиента, что вообще не очень хорошо. Раз уж делаете API, то вынесите его на один адрес, а шаблоны, скрипты и стили клиента на другой. Тут, по-моему, не новый подход к разработке, а нарушение уже устоявшихся.
                                                                API для того и существует чтобы предоставлять данные для ЛЮБОГО интерфейса, и HTML-клиент лишь один из нескольких возможных. Если появятся для этого API клиенты на iOS или Android, то им тоже надо знать где лежат шаблоны books-index?
                                                                  0
                                                                  «смешали логику и шаблоны клиента» — нету никакой логики шаблонов.
                                                                  По сути и шаблонизаторы на сервере не нужны, потому что там шаблонов нет. Возвращается каркас html без данных вообще.
                                                                  Максимум можно комбинировать кусок с header и footer и статичный кусок страницы, это можно даже include обычным сделать.
                                                                  Больше логики html никакой на back-end нету.
                                                                    0
                                                                    шаблоны еще клиентские бывают )
                                                                      0
                                                                      Ага. И вот тут к нам приходят уже заранее подключенные на статическую страницу js компоненты или другие штуки которые вам нравятся.

                                                                      Они то всю динамику и логику интерфейса и делают.
                                                                      То есть можно сделать компонент, шаблонизатор для него и в перед. И страница будет вообще работать как отдельное приложение. Каждая страница сервиса!
                                                                    0
                                                                    «Если появятся для этого API клиенты на iOS или Android, то им тоже надо знать где лежат шаблоны books-index?» — нет, суть в том что само веб приложение есть API.

                                                                    Проще говоря, почему мы не можем html через API слать, но html этот не содержит логики, это просто кусок html — меню, header, footer и прочие вещи которые не меняются.

                                                                    На эту же страницу ставятся js компоненты или другие штуки, они то всю динамику и логику интерфейса и делают.

                                                                    А для мобильников все так же, просто они не используют запросы которые возвращают html статику :-)
                                                                    Вот и все.
                                                                      0
                                                                      Суть как раз в том, что API не должно быть веб-приложением. Оно само по себе, это просто интерфейс для доступа к данным.

                                                                      «Проще говоря, почему мы не можем html через API слать, но html этот не содержит логики, это просто кусок html — меню, header, footer и прочие вещи которые не меняются.»

                                                                      Можете, но это уже не API. Вы просто выдаете клиентские шаблоны для страниц.

                                                                      «А для мобильников все так же, просто они не используют запросы которые возвращают html статику :-)»

                                                                      Вы просто смешали чати приложения и API вместе, а потом говорите программисту «используй только эту часть, это true-API, а это чать веб-приложения». А потом вам понадобится дать доступ к API другим программистам, чтобы они на его основе сделали свое мобильное приложение и вы им выдадите вот это все. Они, конечно же, зададут вам вопросы «нафига нам html странички?», на что вы им скажете что это торчат части другого клиента и им их использовать не надо.

                                                                      Пройдет время, вы захотите поменять свои веб-странички выдаваемые API и… в этот момент в комнату влетает разгневанный начальник/клиент/заказчик и кричит «верни все назад, у команды из Индии/Китая/Другой страны все рухнуло, это ты виноват!». И знаете, он будет прав, потому что кто-то из той команды программистов заиспользовал ваши html-шаблоны и теперь вы с ними связаны и не можете обновить ваш сайт.

                                                                      А еще спустя какое-то время, вас попросят выкатить новую версию API, с немного другими шаблонами. И, вуа-ля, у вас уже три версии html-страничек: для старого API, нового API и вашего нового сайта.
                                                                        –2
                                                                        Такс. Окей.
                                                                        А зачем мобильникам эти страницы ?)

                                                                        Не используют и что. Даже если в страницах что то поменяется от этого ничего не измениться.
                                                                        «Пройдет время, вы захотите поменять свои веб-странички выдаваемые API» — эти страницы часть веб клиента, в чем проблема если они поменяются?)

                                                                        Но Бог с ним. Допустим мы вынесем из API html страницы.

                                                                        Самое главное что веб приложение будет так же работать через REST API.

                                                                          0
                                                                          «А зачем мобильникам эти страницы ?) „

                                                                          Да мало ли что взбредет в голову программистам, которым вы дадите это API. Может захотят сделать какие-то страницы внутри приложения на html.
                                                                          Если в страницах (а это воспринимается как часть API) что-то изменится, то формально поменяется API.

                                                                          “Самое главное что веб приложение будет так же работать через REST API.»

                                                                          Вот об этом вам и говорят, что у вас просто веб-приложение работает через REST API, это не новый подход. Он давно практикуется в случаях, когда нужно чтобы на выходе и API было и приложение. И чтобы не писать для приложения отдельный back-end, его просто заменяют на API. А дальше, как правило, MVC-фреймворк на клиенте.

                                                                          Сама разработка в таком случае строится на том, что параллельно с клиентской частью на html пишется API, которое просто выдает данные ничего не зная о специфике клиента. На стороне браузера, как правило, SPA, который просто с сервера подтягивает статичные шаблоны страниц и манипулирует ими. Вообще как устроен клиент, в данном случае не столь важно, т.к. к REST API можно прикрутить что угодно. Важно лишь то, что клиент отдельно, API отдельно.
                                                                      –1
                                                                      Для мобильников все по старому.

                                                                      Это штука только для веб интерфейса.
                                                                      0
                                                                      Есть же изоморфные/универстальные СПА, где один и тот же код рендерится и на сервере на клиенте, так что все ваши пункты теряют актуальность при таком подходе
                                                                        –3
                                                                        В моем случаи на сервере вообще ничего не рендерится.))))
                                                                          +2
                                                                          Мне все больше кажется, что вы троль! :)
                                                                        0

                                                                        А затем вдруг часть состояния с одной страницы нужно передать на другую и начинается гемор с сохранением его куда-то и дальнейшим восстановлением. Через какое-то время приложение становиться достаточно сложным и гемор с постоянным сохранением/восстановлением начинает перекрывать все другие плюсы. Выкидываем всё сделанное, пишем нормальное SPA.

                                                                          +1

                                                                          И самое весёлое, когда часть сохраняемого состояния нужно генерить на сервере, а другую часть восстанавливать на клиенте. Что-то запихиваем в url, что-то в localStorage, ваще ништяк получается))

                                                                          0
                                                                          SPA SPA рознь :)

                                                                          Можно примеры SPA сайтов? :)

                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                          Самое читаемое