Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!14.12.2022
Як працює база Firebase Firestore. Обіцянки про Сінтру
Хочу в цьому вузькому, але публічному колі зобовʼязатись цього року доробити для Сінтри розділ заощаджень (принаймні, свою, технічну сторону.) Вже принаймні цілий рік збираємося, та на цей день заважають більше пріоритети, ніж війна та всі її мороки.
Перше, що доведеться зробити — це спланувати базу.
Як я вже писав, Сінтра працює на базі даних Firebase Firestore. Це дуже незвичайна база даних. Вона добре підходить для застосунків, де кожний користувач працює з обмеженим набором даних.
Оскільки Firestore - то і є ваш бекенд, що напряму спілкується з клієнтським кодом, то обмеження доступу забезпечуються безпосередньо в самій базі. Для цього є система правил безпеки. Вони виконують як валідацію, так і авторизацію. Правила не такі гнучкі, як повноцінний бекенд, проте дозволяють, наприклад. перевірити, чи є у користувача підписка. Статус підписки зберігається в іншому записі, а ось цей запис вже редагується тільки зі хмарної функції. Коли все, що не можна довірити клієнтському коду, можна сховати у хмарні функції, то обмеження системи правил прийнятні.
Наступне, це надзвичайна реактивність Firestore. На клієнті ми не здійснюємо запити до бази — ми підписуємося на зміни, та отримуємо їх автоматично. Це чудово римується з підходом Redux. На сервері також можна підписати на зміни хмарну функцію. Замість того, щоб опитувати базу, і будувати додаток на засадах “потягни, щоб оновити”, у нас все працює в реальному часі. Та, зазначу, це не досягнення нашого коду, а можливість бази.
Нарешті, цікаво, що база Firestore структурована у вкладені колекції документів: в корені є колекції, в них документи, у документа можуть бути вкладені колекції, в них ще документи, і так далі. Головне, на що це впливає — це права доступу — так, якщо розмістити всі документи користувача в підколекції одного корінного документа, то можна впевнено обмежити доступ до них. Також індекси обмежені колекціями. Запити до бази можливі тільки по індексах, що ми створили заздалегідь (або за ID). Тож грамотне розбиття даних по колекціях впливає на швидкодію.
Тож, для розділу заощаджень, потрібно спланувати додаткову структуру колекцій, документів та індексів таку, щоб, в першу чергу, було зручно підписуватись на них на клієнті. Додати їх до правил безпеки. Та після того можна перейти то інтеграції у Redux.