Время идет, технологии растут, а разработка тяжела на перемены. Все больше и больше ресурсов зависят от API (но нет единых стандартов и решений). До сих пор популярен REST... Что бы сделать запрос на такой сервер, необходимо задать header (auth token), указать тип запроса, адрес, задать get параметры, указать параметры в теле и тип этого тела (json/multipart). Возможно я еще что то упустил (на хабре есть отдельная статья про REST). Благо есть axios и fetch и они от части решают проблему с отправкой запросов. Время идет дальше и количество запросов - которые нужно отправлять растет, а код начинает превращаться в свалку копипасты. Иногда делают мини конструкторы или обертки. Большая же часть живет по старинке. Эта часть кода начинает жить в хранилищах (Store). В дальнейшем я буду приводить примеры на основе Vuex (Vue Store), но в целом думаю это актуально и для React и Angular. Почему Vue? Он проще чем React (нет такого многообразия хранилищ) и у меня на нем больше опыта. С Angular - я практически не работал. Первый мой SPA был самописный (конец 2015год - была какая то версия Angular, но она показалась довольно таки медленной). Уже тогда запросы api были проблематичными и над этим была построена обертка.  Количество запросов в том проекте было не так много (10-15), а сам код не претендует ни на что. Это просто работало и было моим первым SPA. Если не брать во внимание Promise и async/await, то это идеологически лучше чем то, что некоторые middle разработчики делают сейчас (просто вызывают axios или fetch, где необходимо). Увы копипаста запросов считается относительно нормальным явлением и для решения дальнейших проблем в axios используют глобальный конфиг. Выглядит это следующим образом. Можно сказать что в этом виноват Vue JS, но по факту эта проблема есть и в React. C Angular я работал очень давно и мало, но судя по документации  и примерам, эта проблема есть и там.  Вернемся обратно к примеру. В этом примере есть ошибка как в глобальном axios конфиге (headers Authorization - передается всегда), так и захордкожены данные url и отсутствие обработки ошибки. Будем честны - это очень плохой код (это один из худших примеров), но это живет в каком то реальном проекте и работает. Я не хочу приводить код junior разработчиков (которые работали на галерах) и решали проблему прелоадера - через setTimeout 3 секунды.  Использование store во многих проектах - не оправдано и только усложняет проект. Многие приготовили @.. для запуска в меня, просто по тому что, кто то сказал - "store это хорошо и без него не куда". Да store - это хорошо, у store есть классный инструмент для дебага (но нужен ли он на самом деле?). Да им (дебагом) приходиться пользоваться, но причина не в том что он классный и удобный, а в том что происходит не понятная вещь и надо понять откуда растут ноги... Это не значит, что нужно полностью отказаться от store (я в нем храню какие то словари, данные пользователя и др. глобальные вещи), нужно сделать его проще и убрать оттуда не нужное. Определимся с тем что такое проблема в текущем контексте. Проблема - это то, что вам придется писать ручками/решать самим сверх стандартного функционала (хотя это может быть гораздо проще). Как можно было заметить - это отсутствие статуса загрузки (это очевидно).  Вторая проблема, есть ли данные в хранилище и можно ли их взять из кеша (это так же пишется ручками). Третья проблема - обработка ошибки.  Четвертая - получение данных по id (по факту - все кладут болт и кладут в одну ячейку). Пятая - конвертация данных. Проблем на самом деле гораздо больше. Пример классического news store для показа детальной информации об одной новости (не будем брать реализацию через список - по мне это так же плохо). Это пример на основе первого что загуглилось. Для примера - не будем использовать константы (с namespase true - их использование становиться еще и проблематичным, но сейчас не об этом). Для решения первой и второй проблемы - нам достаточно добавить в state newsItemStatus: 'CREATE | LOADING | SUCCESS | ERROR'.  Для решения третьей проблемы - можем присваивать данные ошибки в newsItem или создать newsItemError. newsItemError - позволит избежать ошибок if(newsItem) в уже написанном коде (по этому будем использовать этот вариант).  Четвертая проблема возникает - при необходимости отобразить 2 новости на станицу (можно конечно сделать еще 1 store... но это глупо).  Конвертация данных - в целом не очень сложная задача, но ей часто пренебрегают. После решения этих проблем получаем store. В итоге получаем файлы по 100 строк, которые не очень понятны с первого взгляда (и со второго тоже). Так же недоумение для чего нам все это... Ответ - прост, чтоб сделать это: Это приносит еще пару проблем, которые нам надо решать. Одни из самых простых - это показать сообщение с ошибкой (сетевая или серверная) или вывести alert. В таком варианте существование кода и его поддержка проблематична. Это приводит к написанию оберток над store, написанию доп. компонентов. Ко всему этому надо написать документацию. В итоге к простому сайту/админке с тремя сущностями, мы накидываем ~600 лишних строк кода (это пальцем в небо и кажущийся мне минимум). Поддержка и внедрение такого функционала проблематично (к вам  придут новые разработчики и на копипастят ...).  Приведу пример с использованием обертки над store и на сколько уменьшается количество кода (но это для понимания как можно делать, без рассмотрения дополнительных компонентов). Фитбек - такая реализация не понятна и сложна. Тут каждый решает сам - что ему надо. Request Manager - так я называю API SDK для общения с сервером, которую вы пишете сами и затачиваете под свой проект или проекты. Вы можете описать все свои методы или только часть. В целом не корректно сравнивать Request Manager и Store (это разные вещи и решают разные задачи). Проблема только в том, что Store решает проблемы получения данных, те. чем отправлять, как отправлять, куда и тд., хотя не должен знать об этом ничего... Это приводит к раздуванию хранилища и хранению там бесполезных данных, которые могут не очищаться и храниться мертвым грузом. Давайте представим что мы используем Vue без Store и напишем страницу с новостью, как бы мы ее хотели видеть в идеале. По моему, все очень просто. Возникает вопрос, а нужен ли здесь Store если все так просто? Мое мнение - нет. А как же loading, сообщения об ошибке и прочее? Для страниц я использую некоторую надстройку, которая решает эти проблемы. Loading используется глобальный (с одной стороны это не очень хорошо, но решает огромное количество проблем, при отправке форм, долгой загрузке и прочие моменты - тут каждый решает сам) Предобработка данных?На удивление она тоже есть. Я буду делать кучу запросов запросов к серверу?По умолчанию - да. Но есть возможность кешировать конкретные запросы, дописав в одном месте cache: true (но лучше функцию, которая будет отдавать "(string) ключ" или "false"). У меня не возникало проблем, с тем что надо много чего кешировать. Сам cache - пока что очень примитивен. Возможно и вы создавали свой менеджер запросов в том или ином виде. В целом эта задача довольно не обычная. Для моего менеджера запроса прошло более двух лет и получилось отделить ядро от запросов. А сейчас попытаемся частично интегрироваться с  https://reqres.in . Для начала установить пакет npm install js-request-manager Дальше мы просто описываем нашу схему в фай RmReqres Поздравляю, наш менеджер запросов готов. Осталось только вызвать Request Manager делает код чище и решает множество проблем на которые обычно все закрывают глаза. Да он не идеален, но это лучше чем ничего. Наиболее оптимально и привычнее для всех - будет совместное использование Store и Request Manager. Но все таки не стоит перегружать store бесполезной информацией. Для меня же интереснее получить фидбек и возможно кто то захочет по участвовать в этом, а кто то просто будет использовать такое решение, а кто то останется при своем. В общем "Перемен...") Разработчик