Возьмем
https://www.npmjs.com/ и забьем в поиске любое "(название сервиса) api".
Скорее всего найдутся библиотеки, которые уже обертывают данное API (далее - "клиенты"), и могут легко быть интегрированы в ваше Web-приложение на стороне браузера, или на стороне сервера, или в приложение React Native, или Cordova, или Electron.
Но, во-первых, не всегда это так. Есть подобные клиенты, которые работают только на Node.js, потому что используют
вот это. И они не будут работать в браузере или Electron. Хотя само API может разрешать CORS, а в случае с Electron никаких проблем с CORS по-хорошему и не должно быть.
А остальные клиенты используют какой-нибудь
cross-fetch или, еще хуже,
axios.
Это значит, что если вы сами используете
axios, то эта библиотека притащит
cross-fetch. Или наоборот.
И это порождает очевидную проблему: растет размер бандла. Заказчикам не нравится.
А также порождает одну неочевидную. Старые версии
axios или
cross-fetch могут иметь в себе проблемы безопасности. И если клиент давно не обновляли, то там будет старая версия и вы не сможете ничего сделать, разве что форкать.
При этом заказчику неважно, реальна ли та или иная дыра в данном случае или нет. Он просто не поверит.
В общем при неудачном стечении обстоятельств заказчик вам скажет "выкидывай этот клиент нахрен и пиши свой велосипед для API".
Но велосипед - это долго...
Возникает вопрос:
что, если сделать api client библиотеку абстрагированной от http-библиотек?
И способной использовать любую из них.
Понятно, что можно просто заюзать в коде fetch (а вместе с ним - Headers, AbortController и прочее), но не подключать ничего в зависимости. И тогда это будет работать с любой реализацией fetch, с той самой, которую вы используете в своем проекте.
Но, не будет работать с axios. Нужен адаптер.
Отсюда сумрачный гений рождает идею:
сделать такой универсальный интерфейс, на котором можно будет строить api-библиотеки, и к нему сделать набор адаптеров - под fetch, под axios, под XHR и под прочее.
Какой-то функционал fetch/axios при этом придется портировать. Какой-то просто урезать. Но в большинстве случаев этим api-библиотекам не нужно ничего сверхъестественного, так что решение выглядит жизнеспособным. И думается, что такой адаптер будет прибавлять гораздо меньше веса, чем если тащить в проект 2 отдельные http-библиотеки.
И даже когда появится какая-нибудь новая платформа, операционная система с приложениями на JS/TS, и своей уникальной реализацией http, то надо будет просто написать адаптер и
все api-библиотеки, построенные на этой штуке, смогут работать на этой ОС.
