Новости

23.03.2021

Книга «Веб-разработка с применением Node и Express. Полноценное использование стека JavaScript. 2-е издание»

В книге рассматриваются все этапы и компоненты — от серверного рендеринга до разработки API для работы с одностраничными приложениями (SPA). Express является золотой серединой между устоявшимся фреймворком и отсутствием фреймворка вообще, поэтому он оставляет вам определенную свободу при архитектурном выборе. Эта книга предоставит лучшие решения для фронтенд- и бэкенд-разработчиков, использующих Express. Научитесь смотреть на веб-разработку под новым углом! — Создайте систему шаблонизации для отображения динамических данных. — Подробно изучите объекты запроса и отклика, промежуточное ПО и маршрутизацию URL-адресов. — Создайте симуляцию продакшен-среды и выполняйте в ней тестирование. — Научитесь долговременному хранению информации в документных базах данных с помощью MongoDB и в реляционных базах данных — с помощью PostgreSQL. — Открывайте другим программам доступ к вашим ресурсам благодаря API. — Создавайте защищенные приложения с применением аутентификации, авторизации и HTTPS. — Интегрируйтесь с социальными сетями, включайте геолокацию и многое другое. — Внедрите план по запуску и сопровождению вашего приложения. — Освойте критически важные навыки отладки.

Сети доставки контента


Когда вы переводите свой сайт в эксплуатацию, статические ресурсы должны быть выложены где-то в Интернете. Возможно, вы привыкли выкладывать их на том же сервере, где генерируется весь ваш динамический HTML. В нашем примере до сих пор также использовался данный подход: запускаемый командой node meadowlark.js сервер Node/Express раздает как все виды HTML, так и статические ресурсы. Однако, если хотите оптимизировать производительность вашего сайта (или заложить эту возможность на будущее), вам понадобится возможность выкладывать статические ресурсы в сети доставки контента (content delivery network, CDN). CDN — сервер, оптимизированный для доставки статических ресурсов. Он использует специальные заголовки (о которых мы скоро узнаем больше), включающие кэширование в браузере.

Помимо этого, CDN может включать географическую оптимизацию (часто называемую edge caching), то есть статическое содержимое будет доставляться с ближайшего к вашему клиенту сервера. Хотя Интернет очень быстр (конечно, он работает не со скоростью света, но с близкой к ней), данные будут доставляться еще быстрее с расстояния сотни километров, чем тысячи. Экономия времени в каждом отдельном случае незначительна, но, если умножить ее на количество пользователей, запросов и ресурсов, она быстро приобретет внушительные размеры.

На большую часть ваших статических ресурсов будут ссылаться в представлениях HTML

Широко распространена практика статических ссылок в CSS, обычно в свойстве background-image. И наконец, на статические ресурсы иногда ссылаются в JavaScript, например, код JavaScript может динамически менять или вставлять теги

или свойства background-image.

Не стоит беспокоиться о совместном использовании ресурсов разными доменами (CORS) при применении CDN. Загружаемые в HTML внешние ресурсы не подчиняются правилам CORS: вам требуется активизировать CORS только для ресурсов, загружаемых через Ajax (см. главу 15).

Проектирование для CDN

То, как вы будете использовать CDN, зависит от архитектуры вашего сайта. Большинство сетей доставки контента позволяют устанавливать правила маршрутизации, чтобы определить, куда отправлять входящие запросы. Хотя вы можете установить довольно сложные правила маршрутизации, обычно все сводится к отправке запросов статических ресурсов в одно место (как правило, предоставляемое вашей CDN) и запросов динамических конечных точек (динамических страниц или конечных точек API) — в другое.

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

Наиболее простой подход к созданию структуры вашего приложения — сделать динамические и статические ресурсы легко различимыми. Это позволит максимально упростить правила маршрутизации CDN. Хотя этого можно достичь с помощью поддоменов (например, динамические ресурсы выдаются с meadowlark.com, а статические — с static.meadowlark.com), данный подход связан с дополнительными трудностями и усложняет локальную разработку. Более простой способ — использование путей запросов: например, все, что начинается с /public/, — это статические ресурсы, а все остальное — динамические. Подход может отличаться, если вы генерируете содержимое с помощью Express или используете Express с целью предоставления API для одностраничного приложения.

Веб-сайт с рендерингом на стороне сервера

Если вы используете Express для рендеринга динамического HTML (проще говоря, все, что начинается со /static/), это статические ресурсы, а все остальное —динамические. При таком подходе все ваши (динамически генерируемые) URL будут такими, какими вы хотите их видеть (если только они не начинаются со /static/, конечно же!), а все ваши статические ресурсы будут иметь префикс /static/:

До сих пор в этой книге мы использовали промежуточное ПО static, как если бы все статические ресурсы выкладывались в корневом каталоге. Таким образом, помещая статический ресурс foo.png в папку public, мы ссылаемся на него по пути URL /foo.png, а не /static/foo.png. Конечно, можно создать подкаталог static внутри существующего каталога public, и URL для /public/static/foo.png будет /static/foo.png, но это не очень разумно. К счастью, промежуточное ПО static позволяет нам избежать этого — достаточно указать другой путь при вызове app.use:

Теперь в среде разработки мы можем использовать ту же структуру URL, что и при эксплуатации. Если содержимое папки public и CDN синхронизировано, можно ссылаться на статические ресурсы в обоих местах и без проблем переключаться между разработкой и эксплуатацией.

При настройке маршрутизации для CDN (вам нужно будет обратиться к документации по вашей CDN) маршрутизация будет выглядеть следующим образом.

Одностраничные приложения

Одностраничные приложения, как правило, являются противоположностью веб-сайтов с рендерингом на стороне сервера: серверу будет передаваться только API (например, любой запрос, начинающийся с /api), все остальное передается в статическое файловое хранилище.

В главе 16 вы увидели, что можно создать сборку для эксплуатации вашего приложения, в которую войдут все статические ресурсы, загружаемые в CDN. Затем нужно будет только удостовериться, что настройка маршрутизации вашего API корректна. Таким образом, у вас будет следующая маршрутизация.

Узнав, как можно структурировать приложение, чтобы без проблем перейти от разработки к эксплуатации, обратимся к тому, что на самом деле происходит при кэшировании и как это оптимизирует производительность.

Кэширование статических ресурсов

Независимо от того, что вы используете для раздачи статических ресурсов — Express или CDN, стоит разобраться в заголовках HTTP-запросов, которые браузер использует для определения, когда и как кэшировать статические ресурсы.

— Expires/Cache-Control. Эти два заголовка информируют ваш браузер о максимальном количестве времени, в течение которого ресурс может храниться в кэше. Браузер воспринимает их всерьез: если они приказывают ему хранить что-либо в течение месяца, он попросту не станет загружать это заново на протяжении месяца, до тех пор пока оно остается в кэше. Важно понимать, что браузер может удалить изображение из кэша до истечения срока по причинам, которые вы не в состоянии контролировать. Например, пользователь может очистить кэш вручную или браузер может удалить ваш ресурс, чтобы освободить место для чаще посещаемых пользователем ресурсов. Вам необходим только один из этих заголовков. Expires поддерживается более широко, так что предпочтительнее использовать его. Если ресурс находится в кэше и срок его хранения еще не истек, браузер вообще не выполнит запрос GET, что улучшит производительность, особенно на мобильных устройствах.

— Last-Modified/ETag. Обеспечивают своего рода контроль версий: если браузеру необходимо извлечь ресурс, он проверит эти теги до загрузки содержимого. Запрос GET к серверу все же будет выполнен, но, если возвращаемые в этих заголовках значения продемонстрируют браузеру, что ресурс не менялся, к загрузке файла браузер не перейдет. Как можно догадаться по имени, Last-Modified позволяет вам задать дату последнего изменения ресурса. А ETag дает возможность использовать произвольную строку, обычно строку с версией или хеш содержимого.

При выдаче статических ресурсов следует использовать заголовок Expires и либо Last-Modified, либо ETag. Встроенное в Express промежуточное ПО static устанавливает Cache-Control, но не обрабатывает ни Last-Modified, ни ETag. Поэтому для разработки оно подходит, а для эксплуатации — нет.

Если вы решили выкладывать свои статические ресурсы в CDN, такие как Amazon CloudFront, Microsoft Azure, Fastly, Cloudflare, Akamai или StackPath, то получите бонус: большинство таких деталей будут обработаны за вас. Вы сможете произвести точную настройку, хотя настройки по умолчанию в любом из этих сервисов также хороши.

С полным содержанием статьи можно ознакомиться на сайте "Хабрахабр":

https://habr.com/ru/company/piter/blog/542488/


Комментарии: 0

Пока нет комментариев


Оставить комментарий






CAPTCHAОбновить изображение

Наберите текст, изображённый на картинке

Все поля обязательны к заполнению.

Перед публикацией комментарии проходят модерацию.