Мне нужен простой бэкэнд для хранения данных, используемых во внешнем интерфейсе, но я не хочу устанавливать зависимости от firebase. И я также хочу развернуть все это на Vercel.
Было такое желание при разработке моего любимого проекта (без туториалов на ютубе и т.п.). Стек: React, TypeScript, RTK. Первое, что я помню, это Заполнитель JSON. Но у этой услуги есть ограничение: вы не можете разработать API самостоятельно.
Продолжая поиски, я нашел сервис Ложное притворство, но услуга платная и предоставляет только 14-дневную бесплатную пробную версию. Мы, июньцы, еще не зарабатываем 1000 долларов за наносекунду, так что эта опция отпадает сама по себе, хотя кажется очень удобной.
И тут я вспоминаю совет однокурсника по академии(Академия HTMLДоброе утро) – огневая база от Google. Сервис очень приятный с массой возможностей, но есть нюанс. Он заключается в установке зависимостей firebase в корень проекта, чего мне совсем не хотелось делать. Я хотел использовать REST API для операций CRUD без всех этих незнакомых вещей. firebaseConfig, initializeApp, collections и т. д.
Да, установив все по документации, у вас есть масса возможностей, но мне этот способ не подошел. Я на самом деле не очень хотел разбираться во всем этом для простого приложения (на самом деле это оказалось не так просто и не совсем сделать). Все, что мне нужно было, это спроектировать собственный API и взаимодействовать с ним, используя стандартные HTTP-запросы, используя axios.
Итак, выбор услуги сделан. Firebase предлагает множество продуктов для разных нужд.
Для CRUD операций с данными мне подходят 2 сервиса: база данных в реальном времени И База данных Firestore. Различия мне пока не ясны, но кажется, что База данных Firestore для более «тяжелых» приложений, а база данных в реальном времени больше для чатов и т. д., где вам не нужно хранить много данных.
Начинаю изучать документацию и обнаруживаю, что в более-менее знакомом виде REST API имеет база данных в реальном времени, но опять же есть нюанс.
Нюанс в том, что в БД данные создаются в виде объекта со свойствами, значением которых является объект с текущей задачей. Имена свойств корневого объекта (в моем случае tasks) атрибутирует сам firebase. Это имя, которое возвращает нам сервер во время успешного POST. Итак, я нашел следующую структуру данных:
Имея эту информацию, мне нужно было как-то залить данные на сервер, с помощью которого я бы уже создавал фронтенд-фреймворк (без написания фишей. Хотелось работать сразу с реальными данными). Мне в этом помог Фактор. Написав пример структуры, которая мне подошла бы, я сделал свой первый POST-запрос к созданному серверу. Теперь у меня есть данные на удаленном сервере 🙂
Но для работы мне нужны были данные немного в другом виде. мне нужно было хорошее id со значением того же уникального идентификатора, который назначает Firebase.
Всего у меня есть 2 типа данных:
– тип данных, полученных/отправленных на сервер и сохраненных в Магазине
– тип данных, используемый непосредственно в компонентах.
Данные в том виде, в котором они приходят с сервера, я храню в магазине. Избегая хитрых манипуляций, я преобразовываю эти данные в нужный вид уже при вызове useSelector:
Делать.
