DEV Community: Вадим Бударин

vite-plugin-webmanifest

Вадим Бударин — Wed, 31 Jul 2024 12:41:00 +0000

В наши дни, фронтенд-разработка становится все более сложной и многогранной. Создание быстрого и современного веб-приложения требует не только навыков в кодировании, но и знания различных инструментов и технологий. Одним из таких инструментов является Vite, который сейчас является одним из самых популярных инструментов для сборки фронтенда.

Vite - это современный инструмент для сборки фронтенда, разработанный командой Evan You. Он предлагает быструю и эффективную сборку приложений, а также поддержку современных функций и возможностей. Vite использует модульную систему ES Modules, что позволяет разработчикам писать код с использованием современных синтаксических возможностей и импортировать модули по мере необходимости.

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

Еще одной причиной популярности Vite является его поддержка новых функций и возможностей. Vite поддерживает современные синтаксические возможности, такие как JSX, TypeScript и CSS Modules. Он также предлагает возможность использования различных плагинов и инструментов для улучшения процесса сборки.

Наконец, Vite интегрируется хорошо с другими инструментами и плагинами. Он поддерживает популярные фреймворки и библиотеки, такие как Vue.js, React и Angular. Он также имеет широкий спектр плагинов, которые позволяют расширять функциональность Vite под ваши потребности.

Vite очень быстр и решает большинство вопросов при сборке проекта, но оказалось, что в нем нет стандартного плагина для обработки webmanifest и поэтому он его не обрабатывает и кладет в бандл таким каким он есть и поэтому он не генерирует в бандл иконки, которые в нём определены.
В общем если вы попытаетесь собрать ваш проект в Vite - ваш вэб-манифест окажется не рабочим.

Никаких плагинов для трансформации webmanifest я не нашел. В нескольких issue по данному вопросу все рекомендуют забить на иконки для него и класть их в папку public, чтобы при сборке VIte их просто переложил без трансформаций в dist, но это чревато ошибками на клиенте когда вы измените содержимое иконок, а они не отобразятся из-за того, что предыдущие версии иконок уже закешированы в браузере под этими именами.

Есть правда один монстр-плагин vite-plugin-pwa, но это огромный комбайн и предназначен он для создания сервис воркеров на базе workbox. Ставить его и разбираться с его конфигурацией ради корректной генерации webmanifets - это overkill.

Я сам только недавно начал переходить на Vite и как оказалось для написания плагина в нём придется попотеть ничуть не меньше чем при написании плагина для webpack - вам сначала нужно изучить систему плагинов для Vite, а затем изучить строение плагинов в Rollup т.к. Vite является высокоуровневой надстройкой над Rollup.

В общем, изучая Vite более 3-х недель я решил написать плагин, чтобы исправить этот пробел в сборке приложения на Vite.

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

В общем вот сам плагин:
@budarin/vite-plugin-webmanifest

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

Vite.js: собираем приложение для production безопасно

Вадим Бударин — Wed, 17 Jul 2024 16:49:40 +0000

В мире веб-разработки инструменты для сборки приложений играют ключевую роль, помогая разработчикам оптимизировать и упрощать процесс разработки. Одним из таких современных инструментов является Vite.js, который стремительно завоевывает популярность среди фронтенд-разработчиков. В этой статье мы рассмотрим, почему Vite.js стал отличной альтернативой Webpack и как он может упростить жизнь как новичкам, так и опытным разработчикам.

Vite.js: Новый инструмент для сборки приложений

Vite.js — это современный инструмент для разработки фронтенд-приложений, созданный Эваном Ю, автором Vue.js. В отличие от традиционных инструментов сборки, таких как Webpack, Vite предлагает совершенно иной подход, основанный на современных браузерных возможностях и быстрых сборках благодаря использованию ES-модулей и мощного компилятора esbuild.

Быстрее благодаря ES-модулям

Одним из основных преимуществ Vite является его способность использовать нативную поддержку ES-модулей в браузере во время разработки. Это означает, что при запуске сервера разработки Vite не нужно собирать весь проект целиком, а только обрабатывает и отдает файлы, которые действительно изменились. Это значительно ускоряет время запуска проекта и обновления страниц.

Использование esbuild

Для более быстрой трансформации и минификации кода Vite использует esbuild — невероятно быстрый компилятор, написанный на Go. Благодаря esbuild, Vite обеспечивает молниеносную сборку даже для крупных проектов, что особенно заметно при переходе от разработки к production-сборке.

Почему Vite

Хотя Webpack долгое время был стандартом в мире сборщиков JavaScript, но Vite предлагает ряд преимуществ, которые делают его привлекательным выбором для многих проектов:

Скорость: Благодаря своей архитектуре, Vite обеспечивает более быстрый запуск и перезагрузку проекта.
Простота настройки: Vite предлагает "из коробки" поддержку многих популярных фреймворков, таких как Vue.js, React и Preact, минимизируя количество необходимой настройки.
Модульная архитектура: В Vite легко добавлять и настраивать плагины благодаря использованию Rollup под капотом для production-сборки.
Идеально для новичков

Одним из главных преимуществ Vite является его простота в использовании. Для начинающих разработчиков Vite предлагает минимальную конфигурацию и готовность к работе практически сразу после установки. Вам не нужно беспокоиться о сложных конфигурационных файлах или тонкой настройке различных плагинов — все работает "из коробки".

Шаг влево, шаг вправо ...

Однако, как и любой инструмент, Vite не является универсальным решением для всех сценариев. Когда ваши требования выходят за рамки стандартной конфигурации, вам может понадобиться более глубокое понимание Vite и связанных с ним технологий, таких как esbuild и Rollup.

По-умолчанию из коробки Vite предлагает вам собирать приложение для production не учитывая изменения в JavaScript в разных версиях браузеров и считать, что код собирается для браузеров, которые поддерживают модули:

Chrome >=87
Firefox >=78
Safari >=14
Edge >=88

В документации сказано:

Note that by default, Vite only handles syntax transforms and does not cover polyfills. You can check out https://cdnjs.cloudflare.com/polyfill/ which automatically generates polyfill bundles based on the user's browser UserAgent string.

Vite прямо указывает, что он просто преобразует модули в формат, понимаемый браузером, но он ничего не знает и ничего не делает для его поддержки. Те, кто хочет, чтобы его код выполнялся во всех браузерах, даже если его поддержка реализована не во всех из них - идите за полифилами на CDN одного из провайдеров "добра"!
И это после того, как только недавно отгремел скандал с покупкой сервиса для раздачи полифилов китайцами, которые стали вместе с полифилами вам в код вставлять рекламу! И слава Богу что только рекламу вставляли!

В общем стандартная сборка кода для приложения в Vite никуда не годиться и нам нужно ее исправить!
Нам нужно, что бы все необходимые полифилы были применены на этапе сборки приложения без необходимости инжектировать на сайт сторонний код!

Данная проблема решается при помощи @babel/preset-env. Этот пресет во время сборки анализирует исходный код и если обнаруживает, что используется функциональность которая еще не реализована в конкретной версии браузеров из вашего списка - он добавляет в результирующий код полифил для реализации данной функциональности.

Для начала нужно добавить в проект пакеты:

npm add -D @babel/preset-env core-js @rollup/plugin-babel

и затем создать конфиг Vite (если он не был создан) или модифицировать секцию plugins следующим образом:

// vite.config.js

import { defineConfig } from "vite";
import { getBabelOutputPlugin } from '@rollup/plugin-babel';
import { devDependencies } from "./package.json";

return defineConfig(({ mode }) => {
  const isDev = mode === "development";

  return {
    plugins: isDev
      ? [ react() ]
      : [
          react(),
          getBabelOutputPlugin({
              babelrc: false,
              configFile: false,
              presets: [
                [
                  "@babel/preset-env",
                  {
                    modules: false,
                    useBuiltIns: "entry",
                    corejs: {
                      version: devDependencies["core-js"],
                    },
                  },
                ],
              ],
          }),
        ],
  };
});

Теперь после выполнения команды vite build ваша сборка будет содержать полный код для выполнения в любом целевом браузере и без уязвимостей, связанных с инъекцией кода 3-й стороны!

Примечание: в статье рассматривается сборка кода только для браузеров, которые поддерживают модули. Для сборки кода, для браузеров не поддерживающих модули, используйте плагин legacy (там уже используется @babel/preset-env)

Zustand.js - современный, невесомый, производительный и очень гибкий state manager

Вадим Бударин — Tue, 12 Mar 2024 17:06:40 +0000

Zustand.js - современный, невесомый, производительный и очень гибкий state manager.

Статья является расшифровкой части доклада.

И так начнем с официального описания:

Zustand - не большое, быстрое и масштабируемое решение для управления состоянием, основанное на принципах Flux и immutable state. Имеет удобный API, основанный на хуках, не создает лишнего шаблонного кода и не навязывает жестких правил использования. Не имеет проблем с Zombie children и context loss и отлично работает в React concurrency mode.

Zustand работает в любой окружении:

в коде React
в ванильном JavaScript

Его архитектура базируется на publish/subscribe объекте и реализации единственного хука для React.

Легковесный

Тут даже нечего добавить - 693 байта! Не знаю можно ли найти реализацию еще меньше чем эта.

Простой

Zustand имеет простой синтаксис создания хранилища:

const storeHook = create((set, get) => { ... store config ... });

Для примера создадим простое хранилище:

import { create } from 'zustand';

export const useCounterStore = create((set) => ({
    count: 0,

    increment: () => set((state) => ({ count: state.count + 1 })),
    decrement: () => set((state) => ({ count: state.count - 1 })),
}));

В результате создания хранилища мы получаем React хук, который используем для реактивного отображения изменений данных в компонентах.

Хранилище можно создавать и изменять как в контексте приложения React так и в javascript вне контекста React (не каждый стейт-менеджер способен на такое).

Zustand для обнаружения изменений использует иммутабельность - привычные методы работы с данными в React.

В Zustand вы можете создавать столько хранилищ, сколько вашей душе будет угодно.

import { create } from 'zustand';

export const useCatsStore = create((set) => ({
    count: 0,

    increment: () => set((state) => ({ count: state.count + 1 })),
    decrement: () => set((state) => ({ count: state.count - 1 })),
}));

export const useDogsStore = create((set) => ({
    count: 0,

    increment: () => set((state) => ({ count: state.count + 1 })),
    decrement: () => set((state) => ({ count: state.count - 1 })),
}));

Созданный хук имеет простой синтаксис

storeHook: (selector) => selectedState;

где selector - это простая функция для извлечению данных из переданного ей состояния хранилища

const stateData = storeHook((state) => {
    // извлечение данных  из  state
    ...
    return selectedState;
});

Созданный React хук, легко использовать в компонентах

function Counter() {
    const { count, increment } = useCounterStore((state) => state);

    return <button onClick={increment}>{count}</button>;
}

Удобный

Хук для удобства имеет статические методы (методы объекта pub/sub) :

{
    getState: () => state,
    setState: (newState) => void,
    subscribe: (callback) => void,
    ...
}

Статические методы очень удобно использовать в обработчиках

function Counter() {
    const count = useCounterStore((state) => state.counter);

    function onClick() {
        const state = useCounterStore.getState();

        useCounterStore.setState({
            count: state.count + 3;
        });
    }

    return <button onClick={onClick}>{count}</button>;
}

В хранилище можно использовать асинхронные вызовы:

const useCounterStore = create((set) => ({
    count: 0,

    increment: async () => {
        const resp = await fetch('https://my-bank/api/getBalance');
        const { balance } = await resp.json();

        set((state) => {
            return { count: state.count + balance };
        });
    },
}));

Асинхронные вызовы так же можно выполнять и в компоненте

function Counter() {
    const count = useCounterStore((state) => state.counter);

    function onClick() {
        const resp = await fetch('https://my-bank/api/getBalance');
        const { balance } = await resp.json();

        useCounterStore.setState({
            count: count + balance,
        });
    }

    return <button onClick={onClick}>{count}</button>;
}

Методы можно создавать и вне хранилища

const useCounterStore = create(() => ({
    count: 0,
}));

const increment = () => {
    const state = useCounterStore.getState();
    useCounterStore.setState({ count: state.count + 1 });
};

В Zustand как и в Redux можно создавать свои middleware!
С ним поставляются готовые middlewares:

persist: для сохранения/восстановления данных в/из localStorage
immer: для простого мутабельного изменения состояния
devtools: для работы с расширением redux devtools для отладки

Производительный

А чтоже под капотом ?

Привожу наивную реализацию хука Zustand, который отображает его логику

function useStore(selector) {
    const [prevState, setPrevState] = useState(store.getState(selector));

    useEffect(() => {
        const unsubscribe = store.subscribe((newState) => {
            const currentState = selector(newState);

            if (currentState !== prevState) {
                setPrevState(currentState);
            }
        });

        return () => {
            unsubscribe();
        };
    }, [selector]);

    return prevState;
}

В момент инициализации хука из хранилища выбирается текущее состояние для селектора и записывается в состояние хука.
Далее в эффекте производится подписка на изменения pusb/sub объекта хранилища, в которой, при возникновении обновлений данных хранилища, производится выборка данных при помощи селектора. Затем производится сравнение ссылок текущих данных со ссылкой на данные, сохраненные ранее в состоянии хука. Если ссылки не равны ( а мы помним, что при иммутабельном изменении данных в объекте меняются ссылки на данные) - вызывается метод обновления состояния хука.

Куда уж проще и эффективнее !?
Сравнение ссылок это простая и очень эффективная операция

Так как данные хранилища хранятся вне контекста React ( во внешнем объекте pub/sub ) данный хук будет пропускать изменения состояний хранилища между рендерами в Concurrency mode в React 18+, поэтому реальная реализация хука Zustand базируется на новом хуке React для синхронной перерисовки дерева компонент

function useStore(store, selector, equalityFn) {
    return useSyncExternalStoreWithSelector(
        store.subscribe,
        store.getState,
        store.getServerState || store.getInitialState,
        selector,
        equalityFn,
    );
}

В Concurrency mode в случае изменения данных в хранилище React будет прерывать параллельное построение дерева DOM и будет запускать синхронный рендер для того, чтобы отобразить новые изменения данных в хранилище - это гарантирует что ни одно изменение в хранилище не будет пропущено и будет отрисовано.
Команда React работает над тем, чтобы в будущем избежать грубого прерывания параллельной работы React и выполнять своевременную отрисовку изменений в контексте конкурентного режима.

Методы оптимизации

Методы оптимизации вытекают из выше приведенного кода реализации хука - хук напрямую зависит от селектора, поэтому мы должны обеспечить постоянство ссылки на сам селектор и на данне возвращаемые им!

Их всего 3 простых метода оптимизации

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

const countSelector = (state) => state.count;

function Counter() {
    const count = useCounterStore(countSelector);
    return <div>{count}</div>;
}

если селектор имеет параметры - заключите его в useCallback - таким образом мы обеспечим постоянство ссылки на селектор в зависимости от значения параметра

function TodoItem({ id }) {
    const selectTodo = useCallback((state) => state.todos[id], [id]);
    const todo = useTodoStore(selectTodo);

    return (
        <li>
            <span>{todo.id}</span>
            <span>{todo.text}</span>
        </li>
    );
}

если селектор возвращает каждый раз новый объект - оберните вызов селектора в useShallow - если в новом объекте сами данные реально не изменились - хук useShallow выдаст ссылку на ранее сохраненный объект

import { useShallow } from 'zustand/react/shallow';

const selector = (state) => Object.keys(state);

function StoreInfo() {
    const entityNames = useSomeStore(useShallow(selector));
    return (
        <div>
            <div>{entityNames.join(', ')}</div>
        </div>
    );
}

если же селектор имеет и параметры и возвращает новый объект - оберните его в useCallback и затем в useShallow

import { useShallow } from 'zustand/react/shallow';

function TodoItemFieldNames({ id }) {
    const selectFieldNames = useCallback((state) => Object.keys(state.todos[id]), [id]);
    const fieldNames = useTodoStore(useShallow(selectFieldNames));

    return (
        <li>
            <span>{fieldNames.join(', ')}</span>
        </li>
    );
}

Есть еще один "турбо" способ оптимизации отображения изменения данных в хранилище минуя цикл рендера React - использовать подписку на изменения данных и манипулировать элементами DOM напрямую

function Counter() {
    const counterRef = useRef(null);
    const countRef = useRef(useCounterStore.getState().count);

    useEffect(
        () =>
            useCounterStore.subscribe((state) => {
                countRef.current = state.count;
                counterRef.current.textContent = countRef.current;
            }),
        [],
    );

    return (
        <div>
            <span>Count: </span>
            <span ref={counterRef}>{countRef.current}</span>
        </div>
    );
}

При инициализации компонента запоминаем актуальное состояние в мутабельном объекте countRef и при перерисовках компонента отображаем его. В случае срабатывания подписки - получаем новое состояние, записываем его в мутабельный объект countRef и затем изменяем текстовое содержимое ссылки на DOM элемент counterRef.
В случае если затем React по какой-то причине будет перерисовывать наш компонент - у нас всегда будет актуальное состояние хранилища в мутабельном объекте countRef.

Лучшие практики

Все связанные сущности держите в одном хранилище

Zustand позволяет создавать не ограниченное количество хранилищ, но на практике отдельное хранилище нужно создавать только для данных, которые реально не связаны с данными в других хранилищах иначе вы вернетесь в прошлое - известная проблема model hell из MVC и FLUX (большое количество моделей имеющих хаотические связи с не прозрачной логикой взаимодействия с разнонаправленными потоками данных, как правило, всегда ведущих к зацикливанию обновлений и очень долгими отладками по вечерам для обнаружения этих зацикливаний - более подробно в докладе).

В настоящее время молодое поколение разработчиков, не работавших с MVC и FLUX и не изучавших теорию, создающих различные атомные, молекулярные, протонные, нейтронные и всякие кварковые стейт-менеджеры, наступают на грабли, которые индустрия прошла много лет назад. Связанные данные должны хранится в одном хранилище.
Иначе встает вопрос: зачем вы вынесли локальное состояние из компонента Counter в отдельное хранилище? Какие преимущества кроме неудобства и дополнительного кода, с его привнесенной сложностью, это дало?

Создание отдельных хранилищь оправдано лишь для:

реально не зависимых структур данных
для данных в микрофронтах

Методы хранилища создавайте вне его описания

Не смотря на то что Zustand позволяет создавать методы хранилища прямо в нем самом, рекомендую не создавать методы хранилища внутри него - если у вас в хранилище много сущностей или сущности сложные, а их методы обработки достаточно объемные - описание вашего хранилища станет не читаемым, не понимаемым и плохо поддерживаемым.

Размещение методов в отдельных модулях дает еще один бонус - кроме того что мы визуально изолируем код метода, что делает его легче для чтения и понимания, это позволяет легко тестировать метод в изоляции от самого хранилища.

Доступ к данным в хранилище только при помощи его методов!

Я много лет проектировал и сопровождал базы данных, и для меня не понятно почему в подавляющем большинстве проектов часть базы данных, представленная на клиенте хранилищем, являющегося частью бизнес логики данных, не обеспечивает эту бизнес логику!
Нет ни кода по обеспечению целостности данных, ни их непротиворечивости и безопасности!
Подавляющее количество хранилищ состояния приложения, которые я видел промышленной эксплуатации - это простые Json хранилки! Это не хранилище состояния, а именно простые хранилки json.

Если понять, что эти данные и есть то ядро приложения, вокруг которого строится приложение, то становится понятно, что как это хранилище реализовано - таким и будет надежность приложения. Если хранилище (ядро приложения) - это простая Json хранилка - то 99.99% что приложение будет лихорадить от большого количества багов. Так или иначе код по валидации данных будет размазан и дублирован по разным частям приложения. А отсутствие обеспечения целостности данных и их непротиворечивости гарантированно будет приводить к багам которые будут возникать постоянно в большой команде.

Чтобы создать надежное хранилище и тем самым ликвидировать большинство багов в приложении:

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

import { create } from 'zustand';

// никода не экспортируем сам хук с его методами доступа к хранилищу!
const useCounterStore = create(() => ({
    count: 0,
}));

// экспортируем пользовательский хук - не даем доступ ко всему содержимому хранилища
export const useCounter = () => useCounterStore((state) => state.count);

// экспортируем метод
export const increment = () => {
    const state = useCounterStore.getState();
    useCounterStore.setState({ count: state.count + 1 });
};

Так же рекомендую производить полное клонирование данных на входе и на выходе из методов - ни один джун не сломает ваше хранилище путем мутирования данных из хранилища (для эксперимента попробуйте в возвращенных данных изменить что-либо - вы будете не приятно удивлены результатом - вы напрямую измените данные в хранилище).

Инкапсуляция бизнес-логики в методах хранилища так же позволит безболезненно менять стейт-менеджер в случае необходимости.

Заключение:

Если посмотреть на реализацию Zustand и оглянуться на 10 лет назад, когда у нас уже были активные модели типа pub/sub, и нам оставалось лишь объединить весь зоопарк этих моделей в одно хранилище и реализовать аналог хука (что элементарно реализуется в на старых классовых компонентах) можно понять, что в какой-то момент индустрия свернула не туда и мы пошли не за теми и лишь спустя 10 лет мы наконец-то вышли на правильную дорогу: однонаправленный поток данных (компонент -> реакция юзера -> изменение данных в хранилище -> хук для отображения изменений) и хранение связанных структур данных в одном хранилище.

По пути нам пришлось вначале изобрести FLUX, и затем уйти еще дальше в сторону от простого решения на Redux, параллельно на ощупь искать правильное решение при помощи тысяч реализаций стейт менеджеров.

Но хорошо то, что хорошо заканчивается!

Zustand - это просто мечта разработчика!

компактный
простой в использовании
не добавляющий когнитивной нагрузки
производительный
легко оптимизируемый
легко масштабируемый
имеющий легко поддерживаемый код
исключающий проблемы типа Zombie children и context loss
поддерживающий работу в React concurrency mode

Мы используем Zustand практически с момента его появления на свет и испытываем только положительные эмоции от его применения.

Начните активно использовать Zustand в своих проектах - вы будете приятно удивлены простотой и удобством работы с ним.

Как избавиться от постоянной кодогенерации API слоя в веб-приложениях при изменениях на сервере

Вадим Бударин — Tue, 12 Mar 2024 17:06:15 +0000

Как избавиться от постоянной кодогенерации API слоя в веб-приложениях при изменениях на сервере

Большинство компаний регулярно сталкиваются с проблемой постоянной модификации слоя API в своих веб-приложениях в ответ на изменения API сервера. Некоторые из них прибегают к автогенерации кода на основе схем Swagger, другие переписывают код вручную. Однако эти подходы требуют значительных ресурсов и времени, а также часто приводят к избыточному коду, который растет в объеме вместе с количеством задействованных в коде методов API, увеличивая размер бандловI.
В данной статье я хочу поделиться методом, который позволяет избежать этих сложностей.

Давайте начнем с определения сути и назначения API слоя в веб-приложениях. Этот слой представляет собой интерфейс между приложением и бэкэндом, его основные задачи:

предоставление списка доступных методов API и их описание
выполнение запроса к серверу и возврат ответа сервера приложению

Этот слой не должен содержать логику, кроме логики транспортировки данных между фронтендом и бэкэндом. В нем не должно быть никаких дополнительных вычислений или обработки данных - это задача ядра приложения.

Если мы взглянем на ситуацию объективно, мы увидим, что для разработчика изменяются только семантика вызовов методов и их количество в API - остальные аспекты не так важны.

Вопрос, который мучает многих разработчиков: "Почему мне приходится возиться с этим прокси-слоем каждый раз, когда меняется API на бэкэнде?"
Ответ, возможно, уже скрывается в самом вопросе.

Идея очень проста и в то же время гениальна: прокси-объект + TypeScript!

Прокси-объект позволяет нам делать практически все, что мы захотим, а TypeScript не даст нам сделать лишнего - то, чего нет в интерфейсе API!

Свобода действий при ограничениях - это ключ к гармонии!

Прокси-объект позволяет нам "схлопнуть" весь тот однотипный код десятков, сотен методов в слое АПИ, который генерируют инструменты или пишет человек (код по передаче и получению данных) в один метод.

Давайте я вам покажу, как это работает на примере:

const getAPI = (apiUrl) =>
    new Proxy(
        {},
        {
            get(_, method_name) {
                return async (props) => {
                    const apiMethod = camelToSnake(methodName);
                    const httpMethod = apiMethod.split('_')[0].toUpperCase();
                    const isGetMethod = httpMethod === 'GET';
                    const url = new URL(`${apiUrl}/${apiMethod}`);
                    const options = {
                        method: httpMethod,
                        headers: { 'Content-Type': 'application/json' },
                    };

                    if (isGetMethod) {
                        url.search = new URLSearchParams(props).toString();
                    } else {
                        options.body = JSON.stringify(props);
                    }

                    const response = await fetch(url, options);
                    return response.json();
                };
            },
        },
    );

В коде для примера представлена упрощенная реализация логики прокси-объекта API. Допустим мы предполагаем, что имена методов API всегда начинаются с названия HTTP-метода, а реальные имена методов на бэкэнде имеют snake формат записи ( на практике у вас могут быть любые другие условия и соглашения ).

Пример использования прокси-объекта:

const api = getAPI('http://localhost:3000/api');

// С Proxy мы можем писать реальные вызовы методов
api.getTodos();
// --> fetch('http://localhost:3000/api/get_todos?...', { method: 'GET', ... })

api.postTodo({ title: 'test' });
// --> fetch('http://localhost:3000/api/post_todo', { method: 'POST', ... }))

api.deleteTodo({ id: 1 });
// --> fetch('http://localhost:3000/api/delete_todo', { method: 'DELETE', ... }))

// С Proxy никто не запретит нам писать всякую билеберду
api.putLalalalala('lololololo');
// --> fetch('http://localhost:3000/api/put_lalalalala', { method: 'PUT', ... }))

Однако, чтобы ограничить нашу фантазию рамками реальной реализации API, нам необходимо описание API в виде интерфейса на TypeScript.

type Todo = {
    id: number;
    title: string;
};

interface API {
    getTodos: async () => Todo[];
    postTodo: async ({ title: string }) => Todo;
    deleteTodo: async ({ id: number }) => Todo;
}

Давайте дополним реализацию прокси-объекта типами:

import type { API } from '@companyName/api';

const getAPI = (apiUrl) => new Proxy( ... ) as API;

Теперь api будет содержать описания методов API из интерфейса TypeScript, что обеспечивает автоподсказки в IDE и не позволяет нам выходить за рамки реальной реализации. Typescript предоставляет нам описания методов API, производит валидацию параметров и обеспечивает информацией о возвращаемом результате.

Попытка написания вызова не существующего метода:

api.putLalalalala('lololololo');

или любого другого вызова, не соответствующего интерфейсу, приведет к ошибке.

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

Данный подход предполагает, что API имеет строгую систему: ограничена одним протоколом и имеет четкие ограничения, которые можно описать и реализовать в proxy-объекте. Если никакой системы в проектируемом API нет - данный подход ничем ему уже не поможет.

Заключение

Применение связки прокси-объекта и TypeScript для реализации API слоя позволяет существенно упростить процесс разработки и поддержки приложения, избегая постоянного переписывания или генерации кода слоя API в веб-приложении при изменении API на бэкэнде.

Размер вашего слоя API будет постоянно минимальным вне зависимости используете вы десятки или десятки тысячи методов API в коде (сравните это с постоянно растущим размером текущие реализации API на базе сгенерированного или написанного вручную кода).

Более того - данный код может быть единым для многих веб приложений, Его можно оформить в отдельный пакет и использовать во множестве проектов компании.

Способ очень простой, легковесный и требует лишь периодического обновления типов, описывающих интерфейс API.

Проекты, которые использовали кодогенерацию из схем OpenAPI могут для данного подхода генерировать интерфейс API на typescript, благо таких инструментов достаточно.

Перестаньте писать и генерировать и переписывать API слой на каждое изменение сервера API - это давно уже не модно!

Демо проект: https://github.com/budarin/proxy-api-demo