Хочется простой бэк для хранения данных, которые используются на фронтенде, но не хочется устанавливать зависимости Firebase. И еще хочется все это задеплоить на Vercel.
Появилось вот такое желание при разработке своего пет-проекта (без туториалов на ютубе и тд.). Стек: React, TypeScript, RTK. Первое что вспомнил — это JSON Plaseholder. Но у этого сервиса есть ограничение: Вы не можете самостоятельно спроектировать API.
![ресурсы JSON Placeholder ресурсы JSON Placeholder](https://habrastorage.org/getpro/habr/upload_files/9b9/27f/3c0/9b927f3c07f4f4ce8806edc1016e4413.png)
Продолжив поиски я нашел сервис Mockend, но сервис платный и предоставляет только 14 дней free trial. Мы, джуны, пока не зарабатываем 1кк $ в нано-секунду, поэтому такой вариант отпадает сам по себе, хоть и выглядит очень удобным.
И тут я вспоминаю совет однокурсника по академии (HTML academy, привет) — Firebase от Google. Сервис очень крутой с большим количеством возможностей, но есть нюанс. Заключается он в установке зависимостей firebase в корень проекта, что мне делать совсем не хотелось. Хотелось использовать именно REST API для CRUD операций без всех этих не привычных для меня firebaseConfig
, initializeApp
, collections
и тд.
![Install the SDK and initialize Firebase Install the SDK and initialize Firebase](https://habrastorage.org/getpro/habr/upload_files/0d0/565/f64/0d0565f64b028b93c416e34bc19eedc5.png)
![Access Firebase in your app Access Firebase in your app](https://habrastorage.org/getpro/habr/upload_files/01d/82f/b18/01d82fb18917a5416c03e794df173d11.png)
Да, установив все по документации у Вас появляется огромное количество возможностей, но мне данный метод не подходил. На самом деле, не очень хотелось во всем этом разбираться ради простого to-do приложения (по факту оно вышло не таким простым и не совсем to do). Все что мне было нужно — это спроектировать собственное API и взаимодействовать с ним с помощью стандартных HTTP запросов используя axios.
![Product categories Product categories](https://habrastorage.org/getpro/habr/upload_files/a96/8d5/db1/a968d5db1176079adf2cb72bbf026d44.png)
Итак, выбор сервиса сделан. У Firebase есть множество продуктов под разные задачи.
Для CRUD операций с данными мне подходят 2 сервиса: Realtime Database и Firestore Database. Отличия мне пока не особо понятны, но вроде как Firestore Database для более "тяжелых" приложений, в то время как Realtime Database больше для чатов и тд., где не надо хранить большой объем данных.
Начинаю изучать документацию и нахожу, что в более-менее привычном виде REST API есть у Realtime Database, но опять есть нюанс.
![REST API Realtime Database из документации REST API Realtime Database из документации](https://habrastorage.org/getpro/habr/upload_files/133/95f/cdb/13395fcdb138ba8c0ed1a4b2fbf10335.png)
Нюансом является то, что в БД данные создаются в виде объекта со свойствами значением которых является объект с текущей задачей. Имена свойств корневого объекта (в моем случае tasks
) присваивает сам firebase. Именно это имя сервер нам и возвращает при успешном POST. Таким образом пришел к такой структуре данных:
![структура данных моего проекта структура данных моего проекта](https://habrastorage.org/getpro/habr/upload_files/606/c79/e5d/606c79e5d36def46864fa898d8988ea4.png)
Имея эту информацию мне нужно было как то загрузить данные на сервер, с помощью которых я бы уже создавал каркас фронтенда (без написания рыбы. Работать хотелось сразу с реальными данными). В этом мне помог Postman. Написав примерную структуру, которая мне бы подошла, я сделал свой первый POST запрос на созданный сервер. Теперь у меня есть данные на удаленном сервере :)
Но для работы мне нужны были данные немного в инном виде. Мне нужно было свойство id
со значением того самого уникального id, который присваивает Firebase.
Итого имею 2 типа данных:
- тип данных, получаемый / отправляемый на сервер и хранящийся в Store
- тип данных, который используется непосредственно в компонентах.
![типы данных для работы приложения типы данных для работы приложения](https://habrastorage.org/getpro/habr/upload_files/590/032/f83/590032f83ccc3570d96405c0285c0b23.png)
Данные в том виде, как они пришли с сервера, храню в сторе. Путем не хитрых манипуляций преобразую эти данные в нужный вид уже при вызове useSelector:
![преобразование данных при вызове селектора преобразование данных при вызове селектора](https://habrastorage.org/getpro/habr/upload_files/fa6/346/95c/fa634695c973449c846928f690dcab07.png)
Готово.
Kuch
Проблема в этом решении в том, что ты общаешься с базой напрямую через rest с фронта, значит на фронте находятся все данные для управления твоей бд. Значит любой, кто видит твой фронт, может зайти в девтулзы, взять все необходимое и шатать твою базу как хочется
demetr1ss Автор
Это факт) Но если добавить авторизацию (а такая возможность есть тоже через REST API), то возможности шатать базу уже не будет) А для пет-проекта пойдет даже такой вариант
upd. Точнее возможность будет, но в той директории, где пользователь авторизован. Я планирую по-разбираться с авторизацией на своем проекте как раз, не исключено, что я ошибаюсь)
Kuch
Ключ от базы в любом случае захардкожен будет в билде фронта. Либо получать его с сервера и динамически подставлять, но тогда уже нужен север, а ты отходишь от этой концепции. Самым простым вариантом на самом деле будет использовать Google functions, но конечно для этого нужно тащить зависимость. Хотя не понимаю, в чем тут проблема
FODD
Firabase поддерживает правила для доступа к базе, причем как на основе аутентификации, так и на значениях из самой базы.
Для пет проекта можно настроить права достаточно безопасно, и даже утекшие ключи не особо помогут натворить делов
Kuch
тогда придется ограничиваться только ридонли
FODD
Почему же? Дать доступ на запись только в условный
user/${userName}
и пусть творит что хочет, остальным он почти не навредитKuch
Так тогда нужна авторизация, получается нужен север
Andrew0610
В файрбейс авторизация из коробки есть в чем проблема?
Kuch
В том что ее нет на этом проекте
Andrew0610
Ну тебе насчет проекта уже 3 разп ответили что это просто тест пощупать. А с точки зрения разработки аутентификация имеется. В чем твоя мысль кроме как файрбейс г...но и нужен сервер?
Kuch
С точки зрения разработки и сервер имеется. Так можно про все сказать) На данном проекте нет ничего. Мысль моя в том, что я просто дал совет автору, чем может быть плох такой подход.
Пы сы файрбейз топ, у меня около 15 проектов на нем (дб, хостинг, функции, авторизация, аналитика и тд).
demetr1ss Автор
Проблемы нет. Есть желание по-практиковаться в работе с REST, не более
hierarchical
Если нода как бэк работает, юзеры не увидят запросов
Kuch
Причем тут нода, если сервера нет, а фронт напрямую ходит в базу?