Приложение на одной странице: преимущества и недостатки [закрыто]

Я читал о СПА и его преимуществах. Я нахожу большинство из них неубедительными. Есть 3 преимущества, которые вызывают мои сомнения.

Вопрос: Можете ли вы выступить в качестве защитника SPA и доказать, что я ошибаюсь в отношении первых трех утверждений?

                              === ADVANTAGES ===

1. SPA очень хорош для очень отзывчивых сайтов:

Рендеринг на стороне сервера трудно реализовать для всех промежуточных состояний - малые состояния просмотра плохо отображаются на URL-адреса.

Одностраничные приложения отличаются способностью перерисовывать любую часть пользовательского интерфейса, не требуя использования сервера для получения HTML. Это достигается путем отделения данных от представления данных с помощью уровня модели, который обрабатывает данные, и уровня представления, который считывает данные из моделей.

Что плохого в том, чтобы держать слой модели для не-SPA? Является ли SPA единственной совместимой архитектурой с MVC на стороне клиента?

2. При использовании SPA нам не нужно использовать дополнительные запросы к серверу для загрузки страниц.

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

3. Могут ли быть какие-либо другие преимущества? Не слышу ни о чем другом ..

                            === DISADVANTAGES ===

1. Клиент должен включить JavaScript.
2. Только одна точка входа на сайт.
3. Безопасность.

PS Я работал над проектами SPA и non-SPA. И я задаю эти вопросы, потому что мне нужно углубить свое понимание. Не значит навредить сторонникам СПА. Не проси меня прочитать немного больше о СПА. Я просто хочу услышать ваши соображения по этому поводу.

Давайте посмотрим на один из самых популярных СПА сайтов, GMail.

1. SPA очень хорош для очень отзывчивых сайтов:

Рендеринг на стороне сервера не так сложен, как раньше, с помощью простых методов, таких как сохранение хеша в URL или, в последнее время, HTML5pushState . При таком подходе точное состояние веб-приложения внедряется в URL страницы. Как и в GMail, каждый раз, когда вы открываете почту, в URL добавляется специальный хеш-тег. Если скопировать и вставить в другое окно браузера, можно открыть ту же самую почту (при условии, что они могут аутентифицироваться). Этот подход отображается непосредственно на более традиционную строку запроса, разница только в исполнении. С HTML5 pushState () вы можете исключить #hashи использовать полностью классические URL, которые могут разрешаться на сервере при первом запросе, а затем загружаться через ajax при последующих запросах.

2. При использовании SPA нам не нужно использовать дополнительные запросы к серверу для загрузки страниц.

Количество страниц, загруженных пользователем во время посещения моего веб-сайта ?? действительно, сколько писем кто-то читает, когда он / она открывает свою почтовую учетную запись. Я читаю> 50 за один раз. Теперь структура писем почти одинакова. если вы будете использовать схему рендеринга на стороне сервера, сервер будет рендерить ее при каждом запросе (типичный случай). - проблема безопасности - вы не должны / не должны хранить отдельные страницы для администраторов / логина, которые полностью зависят от структуры вашего сайта, например, paytm.com, также создание SPA для веб-сайта не означает, что вы открываете все конечные точки для всех пользователи, я имею в виду, я использую формы авторизации с моим веб-сайтом спа. - в, вероятно, наиболее используемой среде SPA Angular JS разработчик может загрузить весь HTML-храм с веб-сайта, что может быть сделано в зависимости от уровня аутентификации пользователей. предварительная загрузка HTML для всех типов аутентификации isn '

3. Могут ли быть другие преимущества? Не слышу ни о чем другом ..

• в наши дни можно смело предполагать, что на клиенте будут включены браузеры с поддержкой javascript.
• только одна точка входа на сайт. Как я упоминал ранее, поддержание состояния возможно, у вас может быть любое количество точек входа, но вы обязательно должны иметь одну.
• даже в SPA пользователь видит только то, на что у него есть соответствующие права. Вам не нужно вводить все сразу. Загрузка diff html-шаблонов и javascript async также является допустимой частью SPA.

Преимущества, о которых я могу думать:

1. рендеринг HTML, очевидно, требует некоторых ресурсов, теперь каждый пользователь, посещающий ваш сайт, делает это. Также не только рендеринг основных логик теперь выполняется на стороне клиента, а не на стороне сервера.
2. проблемы с датой - я просто указываю клиенту время в формате UTC в заранее заданном формате и даже не беспокоюсь о часовых поясах, которые я позволяю javascript обрабатывать. это большое преимущество по сравнению с тем, где я должен был угадать часовые пояса на основе местоположения, полученного из IP-адреса пользователя.
3. для меня состояние лучше поддерживается в SPA, потому что, как только вы установите переменную, вы знаете, что она будет там. это дает ощущение разработки приложения, а не веб-страницы. Это очень помогает в создании сайтов, таких как foodpanda, flipkart, amazon. потому что, если вы не используете состояние на стороне клиента, вы используете дорогие сеансы.
4. веб-сайты, безусловно, очень отзывчивы - я возьмусь за крайний пример для того, чтобы сделать калькулятор на не-SPA-сайте (я знаю, это странно).

Обновления из комментариев

Похоже, никто не упоминал о сокетах и ​​длинных опросах. Если вы выходите из другого клиента, например, из мобильного приложения, ваш браузер также должен выйти из системы. Если вы не используете SPA, вам придется заново создавать сокет-соединение каждый раз, когда происходит перенаправление. Это также должно работать с любыми обновлениями данных, такими как уведомления, обновление профиля и т. Д.

Альтернативная перспектива: кроме вашего веб-сайта, будет ли ваш проект включать собственное мобильное приложение? Если да, то вы, скорее всего, будете подавать необработанные данные в это собственное приложение с сервера (например, JSON) и выполнять обработку на стороне клиента для их визуализации, правильно? Итак, с этим утверждением, вы уже делаете модель рендеринга на стороне клиента. Теперь возникает вопрос: почему бы вам не использовать ту же модель для веб-версии вашего проекта? Вроде легкая задача. Тогда возникает вопрос, хотите ли вы отображать страницы на стороне сервера только для преимуществ SEO и удобства общих / закладных URL-адресов?

Я прагматик, поэтому я постараюсь посмотреть на это с точки зрения затрат и выгод.

Обратите внимание, что за любой недостаток, который я даю, я признаю, что они разрешимы. Вот почему я не смотрю ни на что как на черно-белое, а скорее на затраты и выгоды.

преимущества

• Более простое отслеживание состояния - нет необходимости использовать файлы cookie, отправку форм, локальное хранилище, хранилище сеансов и т. Д., Чтобы запомнить состояние между загрузками двух страниц.
• Содержимое на каждой странице (верхний колонтитул, нижний колонтитул, логотип, баннер с авторскими правами и т. Д.) Загружается только один раз за типичную сессию браузера.
• Никаких задержек при переключении страниц.

Недостатки

• Мониторинг производительности - связанные руки. Большинство решений для мониторинга производительности на уровне браузера, которые я видел, фокусируются исключительно на времени загрузки страницы, например, времени до первого байта, времени на построение DOM, двусторонней передаче по сети для HTML, событии загрузки и т. Д. Обновление страницы пост-загрузка через AJAX не будет измеряться. Существуют решения, которые позволяют вам использовать свой код для записи явных измерений, например, при нажатии на ссылку, запуске таймера, затем его завершении после рендеринга результатов AJAX и отправки этого отзыва. Например, New Relic поддерживает эту функцию. Используя SPA, вы привязали себя только к нескольким возможным инструментам.
• Тестирование безопасности / проникновения - связанные руки: автоматическое сканирование безопасности может затруднить обнаружение ссылок, когда вся ваша страница динамически создается с помощью структуры SPA. Вероятно, есть решения для этого, но опять же, вы ограничены.
• Пакетирование: легко попасть в ситуацию, когда вы загружаете весь код, необходимый для всего веб-сайта при начальной загрузке страницы, что может работать ужасно для соединений с низкой пропускной способностью. Вы можете связать свои файлы JavaScript и CSS, чтобы попытаться загружать более естественные фрагменты по мере продвижения, но теперь вам нужно поддерживать это отображение и следить за непреднамеренными файлами, которые извлекаются через нереализованные зависимости (только что случилось со мной). Опять решаемо, но с затратами.
• Реорганизация большого взрыва. Если вы хотите внести существенные изменения в архитектуру, например, переключиться с одного фреймворка на другой, чтобы минимизировать риск, желательно внести дополнительные изменения. То есть, начните использовать новое, перенастройте на некоторой основе, например, на страницу, на функцию и т. Д., Затем удалите старую после. В традиционном многостраничном приложении вы можете переключить одну страницу с Angular на React, а затем переключить другую страницу в следующем спринте. Со СПА это все или ничего. Если вы хотите изменить, вы должны изменить все приложение за один раз.
• Сложность навигации: существует инструментарий, помогающий поддерживать навигационный контекст в SPA, например history.js, Angular 2, большинство из которых опираются либо на структуру URL (#), либо на более новый API истории. Если каждая страница была отдельной страницей, вам это не нужно.
• Сложность определения кода: мы, естественно, думаем о веб-сайтах как о страницах. Многостраничное приложение обычно разбивает код на страницу, что способствует удобству обслуживания.

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

Недостатки

1. Клиент должен включить JavaScript. Да, это явный недостаток СПА. В моем случае я знаю, что могу ожидать, что у моих пользователей будет включен JavaScript. Если вы не можете, то вы не можете сделать SPA, точка. Это все равно что пытаться развернуть приложение .NET на машине без установленного .NET Framework.

2. Только одна точка входа на сайт. Я решаю эту проблему с помощью SammyJS . 2-3 дня работы для правильной настройки маршрутизации, и люди смогут создавать закладки с глубокими ссылками в вашем приложении, которые будут работать правильно. Вашему серверу нужно будет предоставить только одну конечную точку - конечную точку «дай мне HTML + CSS + JS для этого приложения» (представьте, что это место загрузки / обновления для предварительно скомпилированного приложения) - и клиентский JavaScript, который вы напишите, будет обработать фактический вход в приложение.

3. Безопасность.Эта проблема не является уникальной для SPA, вы должны иметь дело с безопасностью точно так же, когда у вас есть «старомодное» клиент-серверное приложение (модель HATEOAS с использованием гипертекста для связи между страницами). Просто пользователь делает запросы, а не ваш JavaScript, и что результаты представлены в формате HTML, а не в формате JSON или в каком-либо другом формате данных. В приложении, отличном от SPA, необходимо защитить отдельные страницы на сервере, тогда как в приложении SPA необходимо защитить конечные точки данных. (И, если вы не хотите, чтобы ваш клиент имел доступ ко всему коду, вам нужно также разделить загружаемый JavaScript на отдельные области. Я просто привязываю это к моей системе маршрутизации на основе SammyJS, чтобы браузер только запрашивал вещи, к которым клиент знает, что он должен иметь доступ, основываясь на начальной загрузке ролей пользователя,

преимущества

1. Основным архитектурным преимуществом SPA (о котором редко упоминают) во многих случаях является значительное сокращение «болтливости» вашего приложения. Если вы спроектируете его должным образом, чтобы обрабатывать большую часть обработки на клиенте (в конце концов, все дело), ​​тогда количество запросов к серверу (см. «Возможности для 503 ошибок, которые разрушают ваш пользовательский опыт») значительно сократится. Фактически, SPA позволяет выполнять полностью автономную обработку, которая в некоторых ситуациях огромна .

2. Производительность, безусловно, лучше при рендеринге на стороне клиента, если вы все делаете правильно, но это не самая убедительная причина для создания SPA. (Скорость сети, в конце концов, улучшается.) Только на этой основе не стоит рассматривать SPA.

3. Гибкость в вашем дизайне пользовательского интерфейса, возможно, является еще одним важным преимуществом, которое я обнаружил. После того, как я определил свой API (с SDK в JavaScript), я смог полностью переписать свой интерфейс с нулевым воздействием на сервер, за исключением некоторых статических файлов ресурсов. Попробуйте сделать это с традиционным приложением MVC! :) (Это становится полезным, когда у вас есть проблемы с живым развертыванием и согласованностью версии вашего API.)

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

Один из главных недостатков SPA - SEO. Лишь недавно Google и Bing начали индексировать страницы на основе Ajax, выполняя JavaScript во время сканирования, и все же во многих случаях страницы индексируются неправильно.

При разработке SPA вы будете вынуждены решать вопросы SEO, возможно, после пост-рендеринга всего вашего сайта и создания статических html-снимков для использования сканером. Это потребует серьезных инвестиций в надлежащую инфраструктуру.

Обновление 19.06.16:

С тех пор как я написал этот ответ некоторое время назад, я приобрел гораздо больший опыт работы с одностраничными приложениями (а именно, AngularJS 1.x) - так что у меня есть больше информации, которой можно поделиться.

На мой взгляд, основным недостатком SPA-приложений является SEO, поэтому они ограничены только приложениями «приборной панели». Кроме того, вам будет намного сложнее с кэшированием по сравнению с классическими решениями. Например, в ASP.NET кэширование очень просто - просто включите OutputCaching, и все хорошо: вся HTML-страница будет кэшироваться в соответствии с URL (или любыми другими параметрами). Однако в SPA вам придется самостоятельно обрабатывать кэширование (используя некоторые решения, такие как кэширование второго уровня, кэширование шаблонов и т. Д.).

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

Но если ваша страница в основном предназначена для отображения, например, страницы с условиями обслуживания, то SPA полностью излишним.

Я думаю, что лучше всего иметь сайт со смесью как страниц SPA, так и страниц со статикой / MVC, в зависимости от конкретной страницы.

Например, на одном сайте, который я создаю, пользователь попадает на стандартную страницу индекса MVC. Но затем, когда они переходят к реальному приложению, оно вызывает SPA. Еще одним преимуществом этого является то, что время загрузки SPA не на домашней странице, а на странице приложения. Время загрузки на домашней странице может отвлечь внимание пользователей, впервые использующих сайт.

Этот сценарий немного похож на использование Flash. После нескольких лет опыта количество сайтов, использующих только Flash, упало почти до нуля из-за коэффициента загрузки. Но как компонент страницы он все еще используется.

Для таких компаний, как Google, Amazon и т. Д., Чьи серверы работают с максимальной пропускной способностью в режиме 24/7, сокращение трафика означает реальные деньги - меньше оборудования, меньше энергии, меньше обслуживания. Перенос загрузки ЦП с сервера на клиент окупается, и SPA-центры сияют. Преимущества избыточный вес недостатки на сегодняшний день. Итак, SPA или нет SPA во многом зависит от варианта использования.

Просто для упоминания другого, возможно, не столь очевидного (для веб-разработчиков) варианта использования для SPA: в настоящее время я ищу способ реализации GUI во встроенных системах, и архитектура на основе браузера кажется мне привлекательной. Традиционно для встроенных систем было не так много возможностей для пользовательского интерфейса - Java, Qt, wx и т. Д. Или коммерческих структур. Несколько лет назад Adobe пыталась выйти на рынок со вспышкой, но, похоже, не очень успешно.

В наши дни, поскольку "встроенные системы" столь же мощны, как и мэйнфреймы, несколько лет назад, возможен выход из пользовательского интерфейса на основе браузера, подключенного к блоку управления через REST. Преимущество в том, что огромная палитра инструментов для пользовательского интерфейса бесплатно. (например, Qt требует 20-30 $ за проданную единицу на лицензионных отчислениях плюс 3000-4000 $ за разработчика)

Для такой архитектуры SPA предлагает много преимуществ - например, более знакомый подход к разработке для разработчиков настольных приложений, ограниченный доступ к серверу (часто в автомобильной промышленности пользовательский интерфейс и проблемы системы являются отдельным оборудованием, где системная часть имеет ОС RT).

Поскольку единственным клиентом является встроенный браузер, упомянутые недостатки, такие как JS-доступность, ведение журнала на стороне сервера, безопасность, больше не учитываются.

2. При использовании SPA нам не нужно использовать дополнительные запросы к серверу для загрузки страниц.

Мне еще предстоит многому научиться, но с тех пор, как я начал изучать СПА, я люблю их.

Этот конкретный момент может иметь огромное значение.

Во многих веб-приложениях, которые не являются SPA, вы увидите, что они по-прежнему будут извлекать и добавлять контент на страницы, выполняющие запросы AJAX. Поэтому я думаю, что SPA выходит за рамки рассмотрения следующих вопросов: что, если контент, который будет извлекаться и отображаться с использованием ajax, будет являться целой страницей? а не просто небольшая часть страницы?

Позвольте мне представить сценарий. Считайте, что у вас есть 2 страницы:

1. страница со списком товаров
2. страница для просмотра сведений о конкретном продукте

Учтите, что вы находитесь на странице списка. Затем вы нажимаете на товар, чтобы просмотреть детали. Клиентское приложение вызовет 2 AJAX-запроса:

1. запрос на получение объекта json с подробной информацией о продукте
2. запрос на получение HTML-шаблона, в который будут вставлены данные о продукте

Затем клиентское приложение вставит данные в шаблон HTML и отобразит их.

Затем вы возвращаетесь к списку (для этого не делается никаких запросов!) И открываете другой продукт. На этот раз будет только запрос Ajax, чтобы получить подробную информацию о продукте. HTML-шаблон будет таким же, поэтому вам не нужно загружать снова.

Вы можете сказать, что в не SPA, когда вы открываете информацию о продукте, вы делаете только 1 запрос, и в этом случае мы сделали 2. Да. Но вы получаете выгоду от общей перспективы, когда вы перемещаетесь по многим страницам, количество запросов будет меньше. И данные, которые передаются между клиентской стороной и сервером, также будут ниже, потому что HTML-шаблоны будут использоваться повторно. Кроме того, вам не нужно загружать в каждом запросе все те CSS, изображения, файлы JavaScript, которые присутствуют на всех страницах.

Также давайте рассмотрим, что ваш серверный язык - это Java. Если вы проанализируете 2 запроса, которые я упомянул, 1 загружает данные (вам не нужно загружать какой-либо файл представления и вызывать механизм визуализации представления), а также другие загрузки и статический HTML-шаблон, чтобы вы могли иметь веб-сервер HTTP, который может извлекать это напрямую, без вызова сервера приложений Java, никаких вычислений не делается!

Наконец, крупные компании используют SPA: Facebook, GMail, Amazon. Они не играют, у них есть величайшие инженеры, изучающие все это. Так что, если вы не видите преимуществ, вы можете сначала доверять им и надеяться открыть их в будущем.

Но важно использовать хорошие шаблоны дизайна SPA. Вы можете использовать фреймворк как AngularJS. Не пытайтесь внедрить SPA без использования хороших шаблонов проектирования, потому что у вас может возникнуть беспорядок.

Недостатки : Технически, дизайн и начальная разработка SPA сложны и их можно избежать. Другими причинами отказа от использования данного SPA могут быть:

• а) Безопасность: одностраничное приложение менее защищено по сравнению с традиционными страницами из-за межсайтового скриптинга (XSS).
• б) Утечка памяти: утечка памяти в JavaScript может даже привести к замедлению работы мощного компьютера. Поскольку традиционные веб-сайты поощряют переходить между страницами, любая утечка памяти, вызванная предыдущей страницей, почти полностью очищается, оставляя меньше следов.
• c) Клиент должен включить JavaScript для запуска SPA, но в многостраничном приложении JavaScript можно полностью избежать.
• г) СПА растет до оптимального размера, вызывает длительное время ожидания. Например: работа в Gmail с более медленным соединением.

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

Эта ссылка объясняет преимущества и недостатки одностраничного приложения.

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

• Потенциал для меньшего количества запросов к серверу, так как рендеринг нового контента не всегда или даже не запрашивается сервером http для новой html-страницы. Но я считаю потенциальным, потому что новый контент может легко потребовать вызова Ajax для извлечения данных, но эти данные могут быть постепенно легче, чем сама разметка плюс, обеспечивая чистую выгоду.

• Способность поддерживать «Государство». Проще говоря, установите переменную при входе в приложение, и оно будет доступно для других компонентов на протяжении всего опыта пользователя, не передавая его и не устанавливая его в локальном хранилище. Интеллектуальное управление этой способностью, однако, является ключом к сохранению беспрепятственного объема верхнего уровня.

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

Старайтесь не рассматривать использование SPA без предварительного определения того, как вы будете решать вопросы безопасности и стабильности API на стороне сервера. Тогда вы увидите некоторые истинные преимущества использования SPA. В частности, если вы используете сервер RESTful, который реализует OAUTH 2.0 для безопасности, вы достигнете двух основных разделений, которые могут снизить ваши затраты на разработку и обслуживание.

1. Это переместит сеанс (и его безопасность) в SPA и избавит ваш сервер от всех этих накладных расходов.
2. Ваши API становятся стабильными и легко расширяемыми.

Намекнул ранее, но не сделал явным; Если ваша цель заключается в развертывании приложений Android и Apple, написание JavaScript SPA, заключенного в собственный вызов для размещения экрана в браузере (Android или Apple), устраняет необходимость поддерживать как кодовую базу Apple, так и кодовую базу Android.

Я понимаю, что это старый вопрос, но я хотел бы добавить еще один недостаток одностраничных приложений:

Если вы создаете API, который возвращает результаты на языке данных (например, XML или JSON), а не на языке форматирования (например, HTML), вы обеспечите большую совместимость приложений, например, в приложениях для бизнеса (B2B). Такая совместимость имеет большие преимущества, но позволяет людям писать программное обеспечение для «добычи» (или кражи) ваших данных. Этот конкретный недостаток является общим для всех API, которые используют язык данных, а не для SPA в целом (действительно, SPA, который запрашивает у сервера предварительный рендеринг HTML, избегает этого, но за счет плохого разделения модели / представления). Этот риск, связанный с этим недостатком, может быть уменьшен различными способами, такими как ограничение запросов и блокировка соединений и т. Д.