Я читал о СПА и его преимуществах. Я нахожу большинство из них неубедительными. Есть 3 преимущества, которые вызывают мои сомнения.
Вопрос: Можете ли вы выступить в качестве защитника SPA и доказать, что я ошибаюсь в отношении первых трех утверждений?
=== ADVANTAGES ===
1. SPA очень хорош для очень отзывчивых сайтов:
Рендеринг на стороне сервера трудно реализовать для всех промежуточных состояний - малые состояния просмотра плохо отображаются на URL-адреса.
Одностраничные приложения отличаются способностью перерисовывать любую часть пользовательского интерфейса, не требуя использования сервера для получения HTML. Это достигается путем отделения данных от представления данных с помощью уровня модели, который обрабатывает данные, и уровня представления, который считывает данные из моделей.
Что плохого в том, чтобы держать слой модели для не-SPA? Является ли SPA единственной совместимой архитектурой с MVC на стороне клиента?
2. При использовании SPA нам не нужно использовать дополнительные запросы к серверу для загрузки страниц.
Ха, а сколько страниц пользователь может загрузить во время посещения вашего сайта? Два три? Вместо этого возникают другие проблемы с безопасностью, и вам нужно разделить страницу входа, страницу администратора и т. Д. На отдельные страницы. В свою очередь это противоречит архитектуре SPA.
3. Могут ли быть какие-либо другие преимущества? Не слышу ни о чем другом ..
=== DISADVANTAGES ===
- Клиент должен включить JavaScript.
- Только одна точка входа на сайт.
- Безопасность.
PS Я работал над проектами SPA и non-SPA. И я задаю эти вопросы, потому что мне нужно углубить свое понимание. Не значит навредить сторонникам СПА. Не проси меня прочитать немного больше о СПА. Я просто хочу услышать ваши соображения по этому поводу.
Ответы:
Давайте посмотрим на один из самых популярных СПА сайтов, GMail.
1. SPA очень хорош для очень отзывчивых сайтов:
Рендеринг на стороне сервера не так сложен, как раньше, с помощью простых методов, таких как сохранение хеша в URL или, в последнее время, HTML5
pushState
. При таком подходе точное состояние веб-приложения внедряется в URL страницы. Как и в GMail, каждый раз, когда вы открываете почту, в URL добавляется специальный хеш-тег. Если скопировать и вставить в другое окно браузера, можно открыть ту же самую почту (при условии, что они могут аутентифицироваться). Этот подход отображается непосредственно на более традиционную строку запроса, разница только в исполнении. С HTML5 pushState () вы можете исключить#hash
и использовать полностью классические URL, которые могут разрешаться на сервере при первом запросе, а затем загружаться через ajax при последующих запросах.2. При использовании SPA нам не нужно использовать дополнительные запросы к серверу для загрузки страниц.
Количество страниц, загруженных пользователем во время посещения моего веб-сайта ?? действительно, сколько писем кто-то читает, когда он / она открывает свою почтовую учетную запись. Я читаю> 50 за один раз. Теперь структура писем почти одинакова. если вы будете использовать схему рендеринга на стороне сервера, сервер будет рендерить ее при каждом запросе (типичный случай). - проблема безопасности - вы не должны / не должны хранить отдельные страницы для администраторов / логина, которые полностью зависят от структуры вашего сайта, например, paytm.com, также создание SPA для веб-сайта не означает, что вы открываете все конечные точки для всех пользователи, я имею в виду, я использую формы авторизации с моим веб-сайтом спа. - в, вероятно, наиболее используемой среде SPA Angular JS разработчик может загрузить весь HTML-храм с веб-сайта, что может быть сделано в зависимости от уровня аутентификации пользователей. предварительная загрузка HTML для всех типов аутентификации isn '
3. Могут ли быть другие преимущества? Не слышу ни о чем другом ..
Преимущества, о которых я могу думать:
Обновления из комментариев
источник
Я прагматик, поэтому я постараюсь посмотреть на это с точки зрения затрат и выгод.
Обратите внимание, что за любой недостаток, который я даю, я признаю, что они разрешимы. Вот почему я не смотрю ни на что как на черно-белое, а скорее на затраты и выгоды.
преимущества
Недостатки
Опять же, я признаю, что каждая из этих проблем решаема, за какую-то цену. Но наступает момент, когда вы тратите все свое время на решение проблем, которых вы могли бы просто избежать. Это касается преимуществ и того, насколько они важны для вас.
источник
Недостатки
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, чтобы браузер только запрашивал вещи, к которым клиент знает, что он должен иметь доступ, основываясь на начальной загрузке ролей пользователя,
преимущества
Основным архитектурным преимуществом SPA (о котором редко упоминают) во многих случаях является значительное сокращение «болтливости» вашего приложения. Если вы спроектируете его должным образом, чтобы обрабатывать большую часть обработки на клиенте (в конце концов, все дело), тогда количество запросов к серверу (см. «Возможности для 503 ошибок, которые разрушают ваш пользовательский опыт») значительно сократится. Фактически, SPA позволяет выполнять полностью автономную обработку, которая в некоторых ситуациях огромна .
Производительность, безусловно, лучше при рендеринге на стороне клиента, если вы все делаете правильно, но это не самая убедительная причина для создания SPA. (Скорость сети, в конце концов, улучшается.) Только на этой основе не стоит рассматривать SPA.
Гибкость в вашем дизайне пользовательского интерфейса, возможно, является еще одним важным преимуществом, которое я обнаружил. После того, как я определил свой 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 страницы:
Учтите, что вы находитесь на странице списка. Затем вы нажимаете на товар, чтобы просмотреть детали. Клиентское приложение вызовет 2 AJAX-запроса:
Затем клиентское приложение вставит данные в шаблон HTML и отобразит их.
Затем вы возвращаетесь к списку (для этого не делается никаких запросов!) И открываете другой продукт. На этот раз будет только запрос Ajax, чтобы получить подробную информацию о продукте. HTML-шаблон будет таким же, поэтому вам не нужно загружать снова.
Вы можете сказать, что в не SPA, когда вы открываете информацию о продукте, вы делаете только 1 запрос, и в этом случае мы сделали 2. Да. Но вы получаете выгоду от общей перспективы, когда вы перемещаетесь по многим страницам, количество запросов будет меньше. И данные, которые передаются между клиентской стороной и сервером, также будут ниже, потому что HTML-шаблоны будут использоваться повторно. Кроме того, вам не нужно загружать в каждом запросе все те CSS, изображения, файлы JavaScript, которые присутствуют на всех страницах.
Также давайте рассмотрим, что ваш серверный язык - это Java. Если вы проанализируете 2 запроса, которые я упомянул, 1 загружает данные (вам не нужно загружать какой-либо файл представления и вызывать механизм визуализации представления), а также другие загрузки и статический HTML-шаблон, чтобы вы могли иметь веб-сервер HTTP, который может извлекать это напрямую, без вызова сервера приложений Java, никаких вычислений не делается!
Наконец, крупные компании используют SPA: Facebook, GMail, Amazon. Они не играют, у них есть величайшие инженеры, изучающие все это. Так что, если вы не видите преимуществ, вы можете сначала доверять им и надеяться открыть их в будущем.
Но важно использовать хорошие шаблоны дизайна SPA. Вы можете использовать фреймворк как AngularJS. Не пытайтесь внедрить SPA без использования хороших шаблонов проектирования, потому что у вас может возникнуть беспорядок.
источник
Недостатки : Технически, дизайн и начальная разработка SPA сложны и их можно избежать. Другими причинами отказа от использования данного SPA могут быть:
Помимо вышесказанного, другими архитектурными ограничениями являются потеря навигационных данных, отсутствие журнала истории навигации в браузере и сложность автоматического функционального тестирования с селеном.
Эта ссылка объясняет преимущества и недостатки одностраничного приложения.
источник
В своем развитии я обнаружил два явных преимущества использования SPA. Это не означает, что в традиционном веб-приложении невозможно достичь следующего, просто я вижу дополнительные преимущества без дополнительных недостатков.
Потенциал для меньшего количества запросов к серверу, так как рендеринг нового контента не всегда или даже не запрашивается сервером http для новой html-страницы. Но я считаю потенциальным, потому что новый контент может легко потребовать вызова Ajax для извлечения данных, но эти данные могут быть постепенно легче, чем сама разметка плюс, обеспечивая чистую выгоду.
Способность поддерживать «Государство». Проще говоря, установите переменную при входе в приложение, и оно будет доступно для других компонентов на протяжении всего опыта пользователя, не передавая его и не устанавливая его в локальном хранилище. Интеллектуальное управление этой способностью, однако, является ключом к сохранению беспрепятственного объема верхнего уровня.
Помимо требования JS (что не является сумасшедшим требованием для веб-приложений), другие отмеченные недостатки, по моему мнению, либо не являются специфическими для SPA, либо могут быть смягчены с помощью хороших привычек и моделей развития.
источник
Старайтесь не рассматривать использование SPA без предварительного определения того, как вы будете решать вопросы безопасности и стабильности API на стороне сервера. Тогда вы увидите некоторые истинные преимущества использования SPA. В частности, если вы используете сервер RESTful, который реализует OAUTH 2.0 для безопасности, вы достигнете двух основных разделений, которые могут снизить ваши затраты на разработку и обслуживание.
Намекнул ранее, но не сделал явным; Если ваша цель заключается в развертывании приложений Android и Apple, написание JavaScript SPA, заключенного в собственный вызов для размещения экрана в браузере (Android или Apple), устраняет необходимость поддерживать как кодовую базу Apple, так и кодовую базу Android.
источник
Я понимаю, что это старый вопрос, но я хотел бы добавить еще один недостаток одностраничных приложений:
Если вы создаете API, который возвращает результаты на языке данных (например, XML или JSON), а не на языке форматирования (например, HTML), вы обеспечите большую совместимость приложений, например, в приложениях для бизнеса (B2B). Такая совместимость имеет большие преимущества, но позволяет людям писать программное обеспечение для «добычи» (или кражи) ваших данных. Этот конкретный недостаток является общим для всех API, которые используют язык данных, а не для SPA в целом (действительно, SPA, который запрашивает у сервера предварительный рендеринг HTML, избегает этого, но за счет плохого разделения модели / представления). Этот риск, связанный с этим недостатком, может быть уменьшен различными способами, такими как ограничение запросов и блокировка соединений и т. Д.
источник