Хочется простой бэк для хранения данных, которые используются на фронтенде, но не хочется устанавливать зависимости 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:
Готово.
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
Причем тут нода, если сервера нет, а фронт напрямую ходит в базу?