Автогенерация функций выборки данных с помощью 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. Он позволит быстрее и удобнее генерировать ссылки на изображения на основе заголовков параметров. Это дополнительно оптимизирует загрузку.

Сейчас мы работаем над пошаговой инструкцией для интеграции новой логики в проекты. Так что следите за обновлениями в блоге!

Комментарии (3)


  1. DoktorB
    25.10.2024 12:28

    А где хранятся изображения, которые оптимизированы на стороне сервера nextjs? По факту, используя встроенную в next оптимизацию, изображения обрабатываются на лету, вы повышаете нагрузку на свой сервер, и если захотите ее уменьшить, вам все равно придется кешировать изображения и где-то их хранить.

    В общем, тут зависит от ваших потребностей, конечно…


    1. dev_family Автор
      25.10.2024 12:28

      Next.js имеет собственные настройки кэширования, информацию о которых можно найти в официальной документации - https://nextjs.org/docs/pages/api-reference/components/image#caching-behavior
      А чтобы уменьшить нагрузку на сервер, можно использовать статический рендеринг, который сейчас пропагандирует Vercel в последних версиях. Так же можно делать кэширование в сторе, к примеру redux, либо можно использовать http-кэширование.


      1. DoktorB
        25.10.2024 12:28

        Статический рендеринг, насколько я понимаю, не связан с изображениями, вы же будете их в любом случае динамически подгружать после первичной загрузки страницы

        В общем-то, что я прочитал по ссылке, не противоречит тому, что я имел в виду - оптимизация изображений с помощью nextjs, возможно, не будет выигрышнее, чем оптимизация на вашем бэке в том виде, который вы описывали в начале статьи. Единственное, что вижу из преимуществ - это гибкость настроек и работа инструмента «из коробки»