В React изоморфные приложения относятся к приложениям, которые используют полный или частичный код между клиентом и сервером, и их также можно назвать универсальными приложениями JavaScript; они не требуют рендеринга контента на стороне браузера, но достигают баланса между серверной и серверной частью; рендеринг на стороне браузера, генерировать контент рендеринга на сервере и позволять пользователям видеть страницы с информацией как можно раньше.
Операционная среда этого руководства: система Windows 10, версия 17.0.1, компьютер Dell G3.
Изоморфные приложения, также известные как универсальные приложения JavaScript, относятся к приложениям, которые полностью (или частично) используют общий код между клиентом и сервером. Запустив код JavaScript приложения на стороне сервера, страница может быть предварительно заполнена контентом перед отправкой в браузер, поэтому пользователи могут видеть контент еще до запуска JavaScript браузера. Когда локальный JavaScript запущен, он берет на себя последующие операции взаимодействия и навигации, позволяя пользователям получать плавный интерактивный опыт в одностраничных приложениях за счет быстрой начальной загрузки и рендеринга страниц на стороне сервера.
Что такое изоморфизм
С внезапным ростом популярности Node.js, интерфейсная и серверная разработка опирается на стандартизированный язык программирования, шаблоны страниц, сторонние механизмы зависимостей и т. д. — все это имеет возможности для реализации унификации интерфейсной и серверной части. -конец. React был первым, кто возглавил эту тенденцию, и концепция изоморфизма получила более широкое распространение.
Читателям необходимо понять, что изоморфные приложения не требуют рендеринга контента на стороне браузера, а скорее достигают баланса между рендерингом на стороне сервера и на стороне браузера. Итак, как понять этот баланс?
Генерируйте контент рендеринга на сервере, чтобы пользователи могли видеть информативные страницы как можно раньше. Помимо чистого статического контента, полное приложение также включает в себя различные реакции на события, взаимодействия с пользователем и т. д. Это означает, что сценарии JavaScript должны выполняться на стороне браузера для выполнения таких операций, как привязка событий и обработка асинхронных взаимодействий.
С точки зрения производительности и пользовательского опыта рендеринг на стороне сервера должен отображать наиболее важную, основную и базовую информацию о странице, в то время как на стороне браузера необходимо выполнить дальнейший рендеринг страницы, привязку событий и другие расширенные функции для взаимодействия; Так называемый изоморфизм означает, что передняя и задняя части совместно используют набор кода или логики. В этом наборе кода или логики идеальной ситуацией является оценка существующей структуры DOM и структуры, которая будет отображаться в ходе дальнейшего процесса визуализации. на стороне браузера. Если да, то структура DOM не будет перерисовываться, требуется только привязка событий.
С этой точки зрения изоморфизм отличается от рендеринга на стороне сервера. Изоморфизм больше похож на пересечение рендеринга на стороне сервера и рендеринга на стороне браузера. Он компенсирует различия между рендерингом на стороне сервера и на стороне браузера, так что это одно и то же. набор кода или логика может быть унифицирована. Ядро изоморфизма — это «один и тот же набор кодов», который представляет собой другое измерение, отделенное от углов на обоих концах.
Преимущества и недостатки изоморфизма
Преимущества изоморфизма заключаются в следующем:
Лучшая производительность. Производительность здесь в основном относится к более быстрому рендерингу, более быстрому отображению первого экрана, меньшему количеству файлов и меньшему размеру файла.
Поддержка SEO-оптимизации. После получения запроса сервер вернет относительно полный HTML-документ, содержащий исходное содержимое, что более удобно для сканеров поисковых систем для получения информации и улучшения рейтинга отображения результатов поиска. В то же время более быстрое время загрузки страниц также поможет улучшить рейтинг отображения результатов поиска.
Реализация более гибкая. Рендеринг на стороне сервера выводит только начальное содержимое страницы, а браузеру все равно необходимо выполнить последующую работу для завершения окончательного представления страницы. Таким образом, рендеринг на стороне сервера и рендеринг на стороне браузера по-прежнему могут быть сбалансированы, и в значительной степени может быть достигнуто повторное использование кода.
Более ремонтопригоден. Потому что с помощью таких библиотек, как React, мы можем добиться широкого спектра повторного использования кода, избегая необходимости серверу и браузеру поддерживать два набора кода или логики одновременно. В результате общий объем кода уменьшается, а затраты на обслуживание снижаются.
Более дружелюбен к моделям бюджетного класса. Поскольку первоначальный рендеринг контента выполняется на стороне сервера, он более удобен для моделей младшего уровня и не вызывает появления белого экрана при загрузке страницы.
Более дружелюбна к суровым сетевым средам. При традиционном методе разделения клиентской и серверной частей содержимое страницы будет отображаться только после того, как все сценарии JavaScript будут загружены и выполнены в процессе выполнения большого количества сетевых запросов. несомненно, увеличивает сложность отображения основного содержимого страницы. В этом отношении изоморфные приложения явно имеют преимущества.
Лучший пользовательский опыт. Чтобы более разумно сбалансировать контент, отображаемый на стороне сервера и на стороне браузера, мы можем спроектировать важные основные части страницы, которые должны быть завершены на стороне сервера, в то время как менее важные интерактивные части могут отображаться браузером или после отображается более важный контент. Реализация значительно улучшит взаимодействие с пользователем.
Недостатки изоморфизма заключаются в следующем:
Логика обработки на стороне сервера увеличивается, что увеличивает сложность.
Сервер не может полностью повторно использовать код на стороне браузера.
Добавлено время TTFB (время до первого байта) на стороне сервера. Время TTFB — это время с момента, когда браузер инициирует первоначальный сетевой запрос, до момента получения первого байта от сервера. Он содержит время TCP-соединения, время отправки HTTP-запроса и время получения первого байта ответного сообщения. Потому что получение данных и отрисовка исходного контента страницы неизбежно снизят скорость возврата сервера.
Расширьте свои знания:
Проектирование внешней и внутренней архитектуры, а также концепции рендеринга на стороне сервера.
Концепция рендеринга на стороне сервера или drop-in становится все более популярной. Прежде чем понять, как реализовать серверный рендеринг на основе React, нам необходимо иметь общее представление о «прошлом и настоящем» серверного рендеринга на архитектурном уровне: почему возникает такая концепция, какие могут быть проблемы; решено после реализации этой концепции; рендеринг на стороне сервера. Каковы плюсы и минусы других методов?
Эволюция технологий взаимодействия на стороне и на стороне сервера
На заре веб-разработки архитектура была простой и понятной. В частности, страница создавалась на стороне сервера JSP, PHP и другими инженерами, а браузер отвечал только за ее отображение. В то время интерфейсному инженеру нужно было только добавлять некоторые динамические интерактивные эффекты к статической странице и редко задействовать логику данных и т. д., в то время как внутренний инженер отвечал за содержимое страницы, то есть когда пользователь; запросил страницу, серверная часть обработала ее и вернула полную статическую страницу. Для завершения этих процессов обычно используются механизмы шаблонов. Так что на тот момент не было даже отдельной должности фронтенд-инженера. Даже если таковые имеются, недостатки этого подхода очевидны, например, нечеткое разделение обязанностей между фронт-эндом и бэк-эндом.
Если сотрудники фронт-энда будут разрабатывать шаблоны, он будет чрезвычайно зависеть от внутренней среды, что затруднит максимальное повышение эффективности разработки. В то же время стоимость обмена информацией о форматах данных будет относительно высокой. Кроме того, такая архитектурная модель имеет очень ограниченное пространство для разработки интерфейсных технологий и использования возможностей браузера.
С быстрым развитием интерфейсных технологий, особенно с появлением таких технологий, как AJAX и Node.js, появилась модель архитектуры, разделяющая фронтальную и внутреннюю части. В этом режиме разделение труда между фронтальной и серверной сторонами становится очень четким, а ключевой точкой сотрудничества на обоих концах является интерфейс AJAX. Давайте возьмем страницу доступа пользователя в качестве примера, чтобы шаг за шагом понять эту модель, как показано на рисунке ниже.
