Что такое сетевая архитектура и что она представляет при разработке веб-приложений? Зачем обсуждать сетевую архитектуру в эти дни?
Это могут быть некоторые ваши вопросы после прочтения заголовка этой статьи, и это только подтверждает то, что я объясню в этом посте.
Сетевая архитектура
Что это?
Есть много разных интерпретаций, но я нашел в Википедии ту, которая отвечает всем требованиям:
Сетевая архитектура — это проект сети связи. Это основа для спецификации физических компонентов сети и их функциональной организации и конфигурации , ее принципов работы и процедур , а также форматов данных, используемых при ее работе.
В этом небольшом предложении содержится много информации, но одна деталь, которая удивила меня, это слово « дизайн» . Это напоминает мне о планировании, красоте и функциональности. Речь идет не только о сокетных соединениях, но и о умных способах работы с этими соединениями.
Зачем об этом говорить?
Я попытаюсь проиллюстрировать это на общем примере. Вот вам вопрос: какая строка длиннее?
Мы все знаем, что, несмотря на любые замечания об обратном, правильный ответ заключается в том, что оба имеют одинаковую длину. Однако на этот раз я изменил правила и, на самом деле, есть более длинная линия. Мы так привыкли давать тот же ответ, что просто игнорируем наши инстинкты, и это именно то, что происходит в мире сетевой архитектуры в наши дни.
Все просто: что-то изменилось в том, как устроен мир. Кто-то изменил наши отношения с устройствами и приложениями за последние 5 лет. Однако никто не упомянул, как мы, как разработчики, должны адаптироваться к новым парадигмам, поэтому мы просто продолжаем «давать один и тот же ответ».
Что изменилось?
Изменилась ли сеть? Нет. Это быстрее, но на самом деле это не изменилось. Возможно, нам придется по-разному с этим справляться, если мы хотим создавать более качественные и быстрые приложения. Я считаю, что это может и приведет к огромным изменениям на рынке технологий в ближайшие несколько лет.
Если это не сеть, что, возможно, изменилось так быстро, что мы не можем идти в ногу? Общественные ценности.
Общество чаще всего меняет свои ценности. Если есть что-то, что становится действительно ценным, это время . Время стало самым важным ресурсом для всех, и теперь время на самом деле деньги, и никто больше не хочет тратить их впустую.
Разработчики должны иметь возможность реагировать на новые требования всех пользователей по всему миру. Мы должны сосредоточиться на создании приложений реального времени или, по крайней мере, приложений, которые не заставляют наших пользователей тратить свое время. Нашей миссией должно быть сокращение времени загрузки до нуля!
Узкие
К сожалению, это не так просто. Узкое место всегда есть, и на этот раз это сеть. Как мы должны создавать более быстрые приложения в режиме реального времени, если мы даже не знаем, как наши приложения будут работать на Edge, 3G, 4G или даже обычном проводном соединении?
Где игра на этом?
Если существует рынок, который всегда интересовался приложениями реального времени и адаптивными приложениями, несмотря на сетевые ограничения, то это рынок игр. Мы строим онлайн-игры со времен медленных коммутируемых соединений в 90-х годах. Как они это делают? Задавая себе простой вопрос: если скорость важна, почему мы продолжаем зависеть исключительно от текущей скорости сети?
Результат такого мышления довольно легко визуализировать. Ниже вы можете увидеть разницу между обычным потоком веб-приложений и массовым многопользовательским режимом ролевых игр (MMORPG):
В обычном потоке есть действия, которые приводят к временам ожидания, пока приложение и сервер обрабатывают наш запрос, и интерфейс обновляется.
Но когда мы говорим о сетевых многопользовательских играх, у нас не может быть времени ожидания. Действие не может быть остановлено, чтобы загрузить следующий, поскольку каждый, похоже, разделяет одну и ту же реальность с разных точек зрения. В результате поток будет выглядеть примерно так:
Этот поток возможен только потому, что мы вообще не говорим о скорости, мы говорим о воспринимаемой скорости. Речь идет об обмане, потому что пользователям все равно, что на самом деле происходит в фоновом режиме.
Есть много методов, используемых в играх, которые следуют этой концепции. Мы могли бы и должны применить их к нашему процессу веб-разработки. Мы рассмотрим четыре простых метода, которые могут многое изменить в том, как вы используете для создания приложений.
Фантастическая Четыре Техники
Визуализация в клиенте
Эта техника хорошо известна тем, кто любит передовые технологии. Существует множество фреймворков и библиотек javascript, которые претендуют на звание «лучшего в мире шаблонного решения», и, учитывая все эти опции на рынке, нет оправдания тому, чтобы не найти то, что соответствует вашим потребностям. Это, безусловно, будет иметь огромное значение для производительности вашего приложения и опыта пользователя. Все будет загружено в начале, и интерфейс сможет обновляться сам.
Даже если эта техника довольно распространена, многие люди избегают этой техники. Большинство из них утверждают, что эти библиотеки не поддерживают все устройства и браузеры, имеющиеся на рынке, поэтому они не используют его. Это не имеет никакого смысла.
На секунду давайте сравним браузеры с телевизорами. Представьте, что у нас есть разные типы телевизоров, некоторые высокого качества со всей этой удивительной технологией, наряду с телевизором вашей бабушки 90-х годов, каждый из которых представляет браузер, я не могу сказать, какой кашель :
Существует один единственный сигнал, который отправляется на все телевизоры, независимо от того, что он поддерживает, и каждый из них будет отображать наилучшее возможное изображение. Это называется изящной деградацией , и результат будет примерно таким:
Когда разработчик решает не использовать метод визуализации в клиенте из-за отсутствия поддержки браузера, это будет ожидаемый результат:
Не бойтесь предлагать наилучшее качество для тех, кто может его использовать. Изящная деградация — это простая концепция, которая может многое изменить.
Хранить данные в клиенте
Выполнение меньшего количества запросов может сделать ваше приложение быстрее, но иногда мы не понимаем, как просто хранить некоторые данные в клиенте, а не отправлять их на сервер. Это не только сэкономит вам некоторые ресурсы инфраструктуры, но и поможет избежать ненужных данных в базе данных.
Несколько лет назад было трудно думать о хранении данных в клиенте, все, что у нас было, это файлы cookie и сеансы, и это было недостаточно безопасно и не достаточно, чтобы быть полезным. В HTML5 у нас есть LocalStorage , много места и удивительный API, чтобы все было проще. Почему бы не начать думать дважды, прежде чем делать удаленные запросы ?
Интеллектуальная предварительная нагрузка
Слово, которое лучше описывает интеллектуальную предзагрузку, — это Предсказание . Обычно, когда мы говорим о прогнозировании, разработчики пугаются. Они начинают задумываться о машинном обучении и огромных формулах, но предсказание может быть довольно простым. Следующие действия, которые ваши пользователи предпримут, — это те, которые вы должны предложить.
Позвольте мне проиллюстрировать это на примере. Это будет основной поток приложения Instagram:
Люди думают, что их изображение загружается при нажатии кнопки «отправить», но на самом деле ваше изображение начинает загружаться при переходе, представленном красной пунктирной линией.
Приложение предполагает, что после выбора снимка, масштабирования и применения фильтров к изображению наиболее ожидаемым следующим действием будет его обмен. Это не сложно предсказать, верно? Никаких волшебных формул. Приложение начнет загружать ваше изображение, и как только вы нажмете кнопку «отправить», оно будет работать быстрее. Не потому что это быстро, а потому что кажется быстрым.
Если вы начнете создавать интеллектуальные приложения с использованием логики и предварительной загрузки ресурсов путем прогнозирования действий пользователя, это будет иметь огромное значение для восприятия пользователя.
асинхронность
Это термин, который используют все, но лишь немногие обеспокоены реальным предложением, стоящим за ним.
Цель состоит в том, чтобы отделить представление от сервера . Сервер будет отвечать только по запросу интерфейса, а интерфейс обновится сам и не заставит пользователя ждать ответа.
Базовым примером будет интерфейс Gmail на iOS. Все, что вам нужно сделать, чтобы удалить письмо, это выбрать его и нажать «удалить». Электронная почта автоматически и волшебным образом исчезнет, исчезнув из интерфейса. Тем не менее, он еще не был удален, и при этом запрос не был отправлен по проводам. Это произойдет в фоновом режиме.
Дело в том, что электронная почта не видна, и пользователь не смотрит на счетчик или индикатор выполнения. Он может продолжать использовать ваше приложение, будучи уверенным, что это письмо было удалено.
Но что делать, если сервер не работает?
Это не проблема, машины должны выходить из строя.
Просто дайте пользователю знать, что это произошло, и попросите его повторить попытку позже, я гарантирую, что ваш пользователь не разозлится из-за того, что его проинформировали о неудобствах . Однако он сделает это, если вы заставите его смотреть на панель загрузки в течение многих минут, пока ваш интерфейс заблокирован в ожидании ответа сервера.
Давай сделаем это!
Да! Давайте сделаем это, давайте создадим потрясающие приложения с нулевой нагрузкой и временем загрузки, но помните, что серебряной пули не существует. Эти методы не являются решением всех проблем, это просто набор хороших методов, которые используются в играх.
Они представляют новый спектр возможностей для нашего процесса разработки веб-приложений, помогая нам следовать требованиям пользователей. Не забывайте, наша миссия — сократить время загрузки до нуля! ,
Эта статья основана на одном из моих недавних выступлений, которые я имел возможность представить на конференции TakeOff в Лилле, Франция, в январе. Это было довольно забавно, если вы хотите немного посмеяться, вы можете посмотреть это на YouTube .