Хочется простой бэк для хранения данных, которые используются на фронтенде, но не хочется устанавливать зависимости Firebase. И еще хочется все это задеплоить на Vercel.
Появилось вот такое желание при разработке своего пет-проекта (без туториалов на ютубе и тд.). Стек: React, TypeScript, RTK. Первое что вспомнил — это JSON Plaseholder. Но у этого сервиса есть ограничение: Вы не можете самостоятельно спроектировать API.
Продолжив поиски я нашел сервис Mockend, но сервис платный и предоставляет только 14 дней free trial. Мы, джуны, пока не зарабатываем 1кк $ в нано-секунду, поэтому такой вариант отпадает сам по себе, хоть и выглядит очень удобным.
И тут я вспоминаю совет однокурсника по академии (HTML academy, привет) — Firebase от Google. Сервис очень крутой с большим количеством возможностей, но есть нюанс. Заключается он в установке зависимостей firebase в корень проекта, что мне делать совсем не хотелось. Хотелось использовать именно REST API для CRUD операций без всех этих не привычных для меня firebaseConfig, initializeApp, collections и тд.
Да, установив все по документации у Вас появляется огромное количество возможностей, но мне данный метод не подходил. На самом деле, не очень хотелось во всем этом разбираться ради простого to-do приложения (по факту оно вышло не таким простым и не совсем to do). Все что мне было нужно — это спроектировать собственное API и взаимодействовать с ним с помощью стандартных HTTP запросов используя axios.
Итак, выбор сервиса сделан. У Firebase есть множество продуктов под разные задачи.
Для CRUD операций с данными мне подходят 2 сервиса: Realtime Database и Firestore Database. Отличия мне пока не особо понятны, но вроде как Firestore Database для более "тяжелых" приложений, в то время как Realtime Database больше для чатов и тд., где не надо хранить большой объем данных.
Начинаю изучать документацию и нахожу, что в более-менее привычном виде REST API есть у Realtime Database, но опять есть нюанс.
Нюансом является то, что в БД данные создаются в виде объекта со свойствами значением которых является объект с текущей задачей. Имена свойств корневого объекта (в моем случае tasks) присваивает сам firebase. Именно это имя сервер нам и возвращает при успешном POST. Таким образом пришел к такой структуре данных:
Имея эту информацию мне нужно было как то загрузить данные на сервер, с помощью которых я бы уже создавал каркас фронтенда (без написания рыбы. Работать хотелось сразу с реальными данными). В этом мне помог Postman. Написав примерную структуру, которая мне бы подошла, я сделал свой первый POST запрос на созданный сервер. Теперь у меня есть данные на удаленном сервере :)
Но для работы мне нужны были данные немного в инном виде. Мне нужно было свойство id со значением того самого уникального id, который присваивает Firebase.
Итого имею 2 типа данных:
- тип данных, получаемый / отправляемый на сервер и хранящийся в Store
- тип данных, который используется непосредственно в компонентах.
Данные в том виде, как они пришли с сервера, храню в сторе. Путем нехитрых манипуляций преобразую эти данные в нужный вид уже при вызове useSelector:
Готово.
