Хочется простой бэк для хранения данных, которые используются на фронтенде, но не хочется устанавливать зависимости Firebase. И еще хочется все это задеплоить на Vercel.

Появилось вот такое желание при разработке своего пет-проекта (без туториалов на ютубе и тд.). Стек: React, TypeScript, RTK. Первое что вспомнил — это JSON Plaseholder. Но у этого сервиса есть ограничение: Вы не можете самостоятельно спроектировать API.

ресурсы JSON Placeholder
ресурсы JSON Placeholder


Продолжив поиски я нашел сервис 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
Access Firebase in your app
Access Firebase in your app

Да, установив все по документации у Вас появляется огромное количество возможностей, но мне данный метод не подходил. На самом деле, не очень хотелось во всем этом разбираться ради простого to-do приложения (по факту оно вышло не таким простым и не совсем to do). Все что мне было нужно — это спроектировать собственное API и взаимодействовать с ним с помощью стандартных HTTP запросов используя axios.

Product categories
Product categories

Итак, выбор сервиса сделан. У Firebase есть множество продуктов под разные задачи.
Для CRUD операций с данными мне подходят 2 сервиса: Realtime Database и Firestore Database. Отличия мне пока не особо понятны, но вроде как Firestore Database для более "тяжелых" приложений, в то время как Realtime Database больше для чатов и тд., где не надо хранить большой объем данных.
Начинаю изучать документацию и нахожу, что в более-менее привычном виде REST API есть у Realtime Database, но опять есть нюанс.

REST API Realtime Database из документации
REST API Realtime Database из документации

Нюансом является то, что в БД данные создаются в виде объекта со свойствами значением которых является объект с текущей задачей. Имена свойств корневого объекта (в моем случае tasks) присваивает сам firebase. Именно это имя сервер нам и возвращает при успешном POST. Таким образом пришел к такой структуре данных:

структура данных моего проекта
структура данных моего проекта

Имея эту информацию мне нужно было как то загрузить данные на сервер, с помощью которых я бы уже создавал каркас фронтенда (без написания рыбы. Работать хотелось сразу с реальными данными). В этом мне помог Postman. Написав примерную структуру, которая мне бы подошла, я сделал свой первый POST запрос на созданный сервер. Теперь у меня есть данные на удаленном сервере :)

Но для работы мне нужны были данные немного в инном виде. Мне нужно было свойство id со значением того самого уникального id, который присваивает Firebase.
Итого имею 2 типа данных:
- тип данных, получаемый / отправляемый на сервер и хранящийся в Store
- тип данных, который используется непосредственно в компонентах.

типы данных для работы приложения
типы данных для работы приложения

Данные в том виде, как они пришли с сервера, храню в сторе. Путем не хитрых манипуляций преобразую эти данные в нужный вид уже при вызове useSelector:

преобразование данных при вызове селектора
преобразование данных при вызове селектора

Готово.

Комментарии (17)


  1. Kuch
    15.04.2023 05:48
    +13

    Проблема в этом решении в том, что ты общаешься с базой напрямую через rest с фронта, значит на фронте находятся все данные для управления твоей бд. Значит любой, кто видит твой фронт, может зайти в девтулзы, взять все необходимое и шатать твою базу как хочется


    1. demetr1ss Автор
      15.04.2023 05:48
      -4

      Это факт) Но если добавить авторизацию (а такая возможность есть тоже через REST API), то возможности шатать базу уже не будет) А для пет-проекта пойдет даже такой вариант

      upd. Точнее возможность будет, но в той директории, где пользователь авторизован. Я планирую по-разбираться с авторизацией на своем проекте как раз, не исключено, что я ошибаюсь)


      1. Kuch
        15.04.2023 05:48
        +3

        Ключ от базы в любом случае захардкожен будет в билде фронта. Либо получать его с сервера и динамически подставлять, но тогда уже нужен север, а ты отходишь от этой концепции. Самым простым вариантом на самом деле будет использовать Google functions, но конечно для этого нужно тащить зависимость. Хотя не понимаю, в чем тут проблема


        1. FODD
          15.04.2023 05:48

          Firabase поддерживает правила для доступа к базе, причем как на основе аутентификации, так и на значениях из самой базы.
          Для пет проекта можно настроить права достаточно безопасно, и даже утекшие ключи не особо помогут натворить делов


          1. Kuch
            15.04.2023 05:48

            тогда придется ограничиваться только ридонли


            1. FODD
              15.04.2023 05:48

              Почему же? Дать доступ на запись только в условный user/${userName} и пусть творит что хочет, остальным он почти не навредит


              1. Kuch
                15.04.2023 05:48

                Так тогда нужна авторизация, получается нужен север


                1. Andrew0610
                  15.04.2023 05:48

                  В файрбейс авторизация из коробки есть в чем проблема?


                  1. Kuch
                    15.04.2023 05:48
                    +1

                    В том что ее нет на этом проекте


                    1. Andrew0610
                      15.04.2023 05:48

                      Ну тебе насчет проекта уже 3 разп ответили что это просто тест пощупать. А с точки зрения разработки аутентификация имеется. В чем твоя мысль кроме как файрбейс г...но и нужен сервер?


                      1. Kuch
                        15.04.2023 05:48

                        С точки зрения разработки и сервер имеется. Так можно про все сказать) На данном проекте нет ничего. Мысль моя в том, что я просто дал совет автору, чем может быть плох такой подход.
                        Пы сы файрбейз топ, у меня около 15 проектов на нем (дб, хостинг, функции, авторизация, аналитика и тд).


        1. demetr1ss Автор
          15.04.2023 05:48

          Проблемы нет. Есть желание по-практиковаться в работе с REST, не более


    1. hierarchical
      15.04.2023 05:48
      -1

      Если нода как бэк работает, юзеры не увидят запросов


      1. Kuch
        15.04.2023 05:48
        +1

        Причем тут нода, если сервера нет, а фронт напрямую ходит в базу?


  1. Hamlet_dat
    15.04.2023 05:48
    +1

    Strapi лучший!


  1. Andy-Esm
    15.04.2023 05:48
    +1

    Есть еще опесорсный supabase Ну это так до кучи, что было что еще поковырять


    1. demetr1ss Автор
      15.04.2023 05:48

      Спасибо) поковыряю