Автогенерация функций выборки данных с помощью Orval, переработка логики оптимизации изображений с заменой нашего компонента Picture, обновления Next.js 15 и небольшой бонус – наш топ библиотек, которые упростят поддержку и разработку вашего проекта, а также сэкономят время на его инициализацию.
Как использовать Orval для автоматизации разработки
Долгое время мы создавали функции выборки данных вручную. Внедрение Orval помогло автоматизировать этот процесс с полной типизацией данных payload и response.
В результате нам удалось:
Сократить время на разработку;
Убрать ненужные созвоны для постоянных уточнений по проектам;
Привести документацию практически к идеальному состоянию.
Подробнее про опыт настройки Orval на примере реального проекта мы рассказали в этой статье.
Следующий шаг – автоматизировать создание документации, чтобы backend-специалисты больше не писали ее вручную. Но об этом они расскажут сами, когда все получится.
Что изменилось в логике работы с изображениями
Ранее для работы с изображениями мы написали компонент Picture, который включал:
Выбор наиболее подходящего размера изображения;
Ленивую подгрузку;
Blur-версию изображения, которая отображается до загрузки.
Работа компонента была организована следующим образом: бэкенд отправлял структуру с разными размерами изображений, которые нужно использовать при определенных условиях. Например, в зависимости от ширины экрана, поддерживаемого браузером формата или количества пикселей на дюйм.
Пример структуры:
Со временем мы обнаружили в Picture следующие недостатки:
Фронтенд-специалистам приходилось составлять размерную схему изображений для каждого компонента на сайте;
Для хранения каждой сущности с графикой нужны были объемные структуры с ссылками на изображения, что увеличивало размер хранилища и осложняло работу с ним;
Компонент использовал дополнительные библиотеки для работы с canvas из-за взаимодействия с форматом base83, необходимым для blur-версии изображения.
Эти ограничения не позволяли использовали нативные возможности основного фреймворка, с которым мы работаем. Например, оптимизацию изображений.
Поэтому мы решили отказаться от нашего компонента и в корне изменить логику работы.
Мы используем Next.js практически в каждом проекте. Он включает ленивую загрузку, умеет самостоятельно обрезать изображение под нужные размеры и дальше выбирает подходящий вариант. Новая логика предполагает, что мы просто отдаем Next.js изображение, а всё остальное фреймворк делает сам. Кратко опишем, как устроен этот процесс.
Чтобы не загружать заранее подготовленные для разных устройств (tablet, desktop, mobile и т.д.) изображения, мы будем использовать компонент next/image. Он использует параметры deviceSizes и imageSizes в конфигурации Next.js, что позволяет создавать массив изображений с разной шириной. Компонент автоматически генерирует ссылки, в которых с помощью параметра передаётся ширина из массива. Далее браузер делает запрос на сервер Next (обёртка над node.js), а тот уже сжимает изображение до нужного размера и возвращает браузеру.
В next/image можно указывать параметр sizes. Он подсказывает браузеру, какое изображение нужно загрузить в зависимости от ширины экрана. Это позволяет автоматически подбирать наиболее подходящее изображение для текущего устройства, тем самым улучшая производительность. В результате, загружаются картинки нужного размера, а не огромные файлы, которые потом сжимаются на клиенте с потерей качества.
Для создания кастомного загрузчика вместо стандартного, который по умолчанию предлагает Next.js, будем использовать сервис imgproxy. Он позволит быстрее и удобнее генерировать ссылки на изображения на основе заголовков параметров. Это дополнительно оптимизирует загрузку.
Сейчас мы работаем над пошаговой инструкцией для интеграции новой логики в проекты. Так что следите за обновлениями в блоге!
DoktorB
А где хранятся изображения, которые оптимизированы на стороне сервера nextjs? По факту, используя встроенную в next оптимизацию, изображения обрабатываются на лету, вы повышаете нагрузку на свой сервер, и если захотите ее уменьшить, вам все равно придется кешировать изображения и где-то их хранить.
В общем, тут зависит от ваших потребностей, конечно…
dev_family Автор
Next.js имеет собственные настройки кэширования, информацию о которых можно найти в официальной документации - https://nextjs.org/docs/pages/api-reference/components/image#caching-behavior
А чтобы уменьшить нагрузку на сервер, можно использовать статический рендеринг, который сейчас пропагандирует Vercel в последних версиях. Так же можно делать кэширование в сторе, к примеру redux, либо можно использовать http-кэширование.
DoktorB
Статический рендеринг, насколько я понимаю, не связан с изображениями, вы же будете их в любом случае динамически подгружать после первичной загрузки страницы
В общем-то, что я прочитал по ссылке, не противоречит тому, что я имел в виду - оптимизация изображений с помощью nextjs, возможно, не будет выигрышнее, чем оптимизация на вашем бэке в том виде, который вы описывали в начале статьи. Единственное, что вижу из преимуществ - это гибкость настроек и работа инструмента «из коробки»