Застосування однієї сторінки: переваги та недоліки [закрито]

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

Питання: Чи можете ви виступати як захисник SPA та довести, що я помиляюся щодо перших трьох тверджень?

                              === ADVANTAGES ===

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

Відображення на стороні сервера важко реалізувати для всіх проміжних станів - невеликі стани перегляду не добре відображають URL-адреси.

Програми для однієї сторінки відрізняються своєю здатністю перемальовувати будь-яку частину інтерфейсу користувача, не вимагаючи зворотного переходу сервера для отримання HTML. Це досягається відокремленням даних від подання даних за допомогою шару моделі, який обробляє дані, та рівня перегляду, який читається з моделей.

Що не так у триманні шару моделі для не-SPA? Чи SPA є єдиною сумісною архітектурою з MVC на стороні клієнта?

2. За допомогою SPA нам не потрібно використовувати додаткові запити на сервер для завантаження сторінок.

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

3. Чи можуть бути якісь інші переваги? Не чуйте ні про що інше ..

                            === DISADVANTAGES ===

1. Клієнт повинен включити JavaScript.
2. Лише одна точка входу на сайт.
3. Безпека.

PS Я працював над SPA та не-SPA проектами. І я задаю ці питання, тому що мені потрібно поглибити своє розуміння. Не означає шкодити прихильникам SPA. Не вимагайте, щоб я прочитав трохи більше про SPA. Я просто хочу почути ваші міркування з цього приводу.

Давайте розглянемо один з найпопулярніших SPA сайтів, GMail.

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

Візуалізація на стороні сервера не настільки складна, як це було раніше з простими методами, такими як збереження #hash в URL-адресі або останнім часом HTML5pushState . При такому підході точний стан веб-програми вбудовується в URL-адресу сторінки. Як і в GMail, кожного разу, коли ви відкриваєте пошту, до URL-адреси додається спеціальний хеш-тег. Якщо скопійовано та вставлено в інше вікно браузера, можна відкрити таку саму пошту (за умови, що вони можуть автентифікуватись). Цей підхід відображається безпосередньо в більш традиційній рядку запиту, різниця полягає лише у виконанні. За допомогою HTML5 pushState () ви можете усунути #hashта використовувати абсолютно класичні URL-адреси, які можуть вирішитись на сервері за першим запитом, а потім завантажити через ajax на наступні запити.

2. За допомогою SPA нам не потрібно використовувати додаткові запити на сервер для завантаження сторінок.

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

3. Чи можуть бути якісь інші переваги? Не чуйте ні про що інше ..

• в наші дні можна сміливо припускати, що клієнт матиме браузери з підтримкою JavaScript.
• лише одна точка входу на сайт. Як я вже згадував, можливе підтримання стану, ви можете мати будь-яку кількість точок входу, як вам захочеться, але ви повинні мати його точно.
• навіть у користувачі SPA бачать лише те, на що він має належні права. не потрібно вводити кожну річ одразу. завантаження шаблонів різного html та async javascript також є дійсною частиною SPA.

Переваги, про які я можу придумати:

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

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

Схоже, ніхто не згадував про розетки та тривалі опитування. Якщо ви виходите з іншого клієнта, скажімо, мобільний додаток, то ваш веб-переглядач також повинен вийти. Якщо ви не використовуєте SPA, вам доведеться заново створювати з'єднання з розеткою щоразу, коли буде переспрямовано. Це також повинно працювати з будь-якими оновленнями таких даних, як сповіщення, оновлення профілю тощо

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

Я прагматик, тому спробую поглянути на це з точки зору витрат і вигод.

Зауважте, що за будь-якого недоліку, який я надаю, я визнаю, що вони вирішувані. Ось чому я не дивлюсь ні на що як на чорно-біле, а, швидше, на витрати та вигоди.

Переваги

• Легше відстеження стану - не потрібно використовувати файли cookie, подання форми, локальне зберігання, зберігання сеансів тощо, щоб пам’ятати про стан між 2 завантаженнями сторінок.
• Вміст плит котла, який є на кожній сторінці (заголовок, колонтитул, логотип, банер авторських прав тощо), завантажується лише один раз за типовий сеанс браузера.
• Немає затримок на перемиканні "сторінок".

Недоліки

• Моніторинг продуктивності - зв’язані руки: Більшість рішень для моніторингу продуктивності на рівні браузера я бачив, що фокусується виключно на завантаженні сторінки, як, наприклад, час на перший байт, час створення DOM, обхід мережі для HTML, подія завантаження тощо. Оновлення сторінки після навантаження через AJAX не вимірюється. Є рішення, які дозволяють інструментувати ваш код для запису чітких заходів, наприклад, при натисканні на посилання, запустіть таймер, а потім закінчіть таймер після надання результатів AJAX і надішліть цей відгук. Наприклад, New Relic підтримує цю функціональність. Використовуючи SPA, ви прив'язали себе лише до кількох можливих інструментів.
• Тестування безпеки / проникнення - зв’язані руки: Автоматичне сканування безпеки може мати проблеми з виявленням посилань, коли вся ваша сторінка динамічно побудована за допомогою SPA-системи. Напевно, для цього є рішення, але знову ж таки, ви обмежилися.
• Комплектація: Легко потрапити в ситуацію, коли ви завантажуєте весь код, необхідний для всього веб-сайту, при початковому завантаженні сторінки, що може спрацьовувати жахливо при низькосмугових з'єднаннях. Ви можете згрупувати файли JavaScript та CSS, щоб спробувати завантажуватись у більш природні шматки, але тепер вам потрібно підтримувати це картографування і спостерігати за тим, щоб невмілі файли потрапляли через нереалізовані залежності (що трапилось зі мною). Знову вирішувана, але з вартістю.
• Рефакторинг великого удару: Якщо ви хочете внести серйозні архітектурні зміни, наприклад скажіть, перейти від однієї рамки до іншої, щоб мінімізувати ризик, бажано внести додаткові зміни. Тобто почніть використовувати нове, перенесіть на якійсь основі, наприклад, на сторінку, за особливістю тощо, а потім скиньте старе після. За допомогою традиційного багатосторінкового додатка ви можете переключити одну сторінку з кутової на Реактивну, а потім переключити іншу сторінку в наступному спринті. З SPA - це все або нічого. Якщо ви хочете змінити, ви повинні змінити всю програму за один раз.
• Складність навігації: Інструменти існують для того, щоб підтримувати контекст навігації в SPA, як, наприклад, history.js, Angular 2, більшість з яких покладаються на URL-адресу (#) або новіший API історії. Якщо кожна сторінка була окремою сторінкою, вам нічого не потрібно.
• Складність з'ясування коду: Ми, природно, вважаємо веб-сайти як сторінки. Багатосторінковий додаток зазвичай кодує розділи за сторінками, що сприяє ремонту.

Знову ж таки, я визнаю, що кожна з цих проблем вирішується за певну ціну. Але настає момент, коли ви витрачаєте весь свій час на вирішення проблем, яких ви могли б просто уникнути в першу чергу. Це повертається до переваг та того, наскільки вони для вас важливі.

Недоліки

1. Клієнт повинен включити JavaScript. Так, це явний недолік SPA. У моєму випадку я знаю, що можу очікувати, що мої користувачі мають увімкнути JavaScript. Якщо ви не можете, то не можете робити SPA, періодично. Це як спробувати розгорнути додаток .NET на машині без встановленого .NET Framework.

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

3. Безпека.Це питання не характерне лише для SPA, ви повинні мати справу з безпекою точно так само, коли у вас є програма "old-school" клієнт-сервер (модель HATEOAS використання Hypertext для зв'язку між сторінками). Просто користувач робить запити, а не 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: я зараз шукаю спосіб впровадження графічних інтерфейсів у вбудовані системи та архітектуру на основі браузера, мені здається привабливим. Традиційно не було багато можливостей для користувальницьких інтерфейсів у вбудованих системах - Java, Qt, wx тощо або комерційних рамок. Деякі роки тому Adobe намагалася вийти на ринок із спалахом, але, здається, не настільки успішною.

Сьогодні, оскільки «вбудовані системи» настільки потужні, як мейнфрейми кілька років тому, інтерфейс на основі браузера, підключений до блоку управління через REST, є можливим рішенням. Перевага полягає у величезній палітрі інструментів для інтерфейсу без витрат. (наприклад, Qt вимагає 20-30 $ за продану одиницю плати за роялті плюс 3000-4000 $ за розробника)

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

Оскільки єдиним клієнтом є вбудований браузер, згадані недоліки, такі як наявність JS, реєстрація на стороні сервера, безпека більше не враховуються.

2. За допомогою SPA нам не потрібно використовувати додаткові запити на сервер для завантаження сторінок.

Мені ще належить багато чому навчитися, але оскільки я почав вивчати 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 є складним і його можна уникнути. Іншими причинами невикористання цього СПА можуть бути:

• a) Безпека: Застосування однієї сторінки менш захищене порівняно з традиційними сторінками через сценарій міжміських веб-сайтів (XSS).
• b) Витік пам'яті: Витік пам'яті в JavaScript може навіть призвести до уповільнення потужного комп'ютера. Оскільки традиційні веб-сайти заохочують переходити між сторінками, таким чином, будь-яке витоку пам'яті, спричинене попередньою сторінкою, майже очищається, залишаючи менше залишків.
• c) Клієнт повинен увімкнути JavaScript для запуску SPA, але у багатосторінковому застосуванні JavaScript можна повністю уникнути.
• г) SPA зростає до оптимальних розмірів, викликає тривалий час очікування. Напр .: Робота в Gmail із повільнішим підключенням.

Крім вищезазначених, іншими архітектурними обмеженнями є втрата навігаційних даних, відсутність журналу навігаційної історії в браузері та труднощі в автоматизованому функціональному тестуванні з селеном.

Це посилання пояснює переваги та недоліки програми для однієї сторінки.

У своєму розвитку я знайшов дві чіткі переваги використання SPA. Це не означає, що наступного не можна досягти в традиційному веб-додатку, просто я бачу додаткові переваги без введення додаткових недоліків.

• Потенціал для меншого запиту сервера, оскільки надання нового вмісту не завжди або навіть не є запитом сервера http для нової сторінки html. Але я вважаю потенційним, оскільки новий вміст може легко вимагати дзвінка Ajax для отримання даних, але ці дані можуть бути настільки легшими, ніж сам плюс розмітка, що забезпечує чисту користь.

• Здатність підтримувати "Державу". Найпростіше кажучи, встановіть змінну при вході в додаток, і вона буде доступна для інших компонентів протягом усього користувачевого досвіду, не передаючи її навколо і не встановлюючи її на локальну схему зберігання. Однак інтелектуальне управління цією здатністю є ключовим фактором для збереження розмаху верхнього рівня.

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

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

1. Це перемістить сеанс (і це безпека) на SPA та позбавить ваш сервер від усіх цих витрат.
2. Ваш API стає стабільним і легко розширюваним.

Натякали на раніше, але не було явним; Якщо ваша мета - розгортання додатків для Android та Apple, написання SPA SPA, яке завершується натисненням власного дзвінка для розміщення екрана в браузері (Android або Apple), виключає необхідність підтримувати як кодову коду Apple, так і базу коду Android.

Я розумію, що це питання старіше, але я хотів би додати ще один недолік програм на одній сторінці:

Якщо ви створюєте API, який повертає результати в мові даних (наприклад, XML або JSON), а не в мові форматування (наприклад, HTML), ви дозволяєте підвищити сумісність додатків, наприклад, у додатках бізнес-бізнес (B2B). Така сумісність має великі переваги, але дозволяє людям писати програмне забезпечення, щоб "шахта" (або вкрасти) ваші дані. Цей особливий недолік є спільним для всіх API, які використовують мову даних, а не для SPA в цілому (дійсно, SPA, який запитує сервер за попередньо виведеним HTML, уникає цього, але за рахунок поганої розділеності моделі / перегляду). Цей ризик, схильний до цього недоліку, може бути зменшений різними способами, такими як обмеження запиту та блокування з'єднання тощо.