Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 Контент вільний від AI. Цей пост на 100% написаний людиною, як і все на моєму блозі. Насолоджуйтесь!

08.07.2023

Нові розуміння про Firebase Firestore

Не можу не поділитися цим чарівним пейзажем грозової хмари на заході сонця. В небі було таке різноманіття, ніби хтось спеціально робив декорації.

Доробка розділу накопичень для Сінтри примусила глибше вивчити Firebase Firestore.

• База Firestore складається з колекцій, в які вкладені документи, в які знову вкладені колекції, і так далі. Хоча до кожної колекції та документа можна дістатись за повним шляхом — та так я робив раніше — можна спростити код, якщо будувати посилання за допомогою методів collection() та doc(). Це схоже на роботу з асоціаціями в ActiveRecord.

• Транзакції в Firestore є та реалізуються класом WriteBatch. Думаю, не треба пояснювати, що при змінах, що стосуються більш ніж одного документа, транзакції є незамінними для збереження цілісності — навіть не через ризик race condition, а ризик звичайних багів.

• Ідентифікатор документа можна згенерувати миттєво — якщо створити посилання на документ без ідентифікатора, тобто newDocRef = collection.doc(), то newDocRef.id буде заповненим та правильним значенням. Це можливо тому, що це GUID. Тому якщо треба зробити декілька повʼязаних змін в транзакції, або просто повернути ідентифікатор з синхронного виклику — проблем немає. Раніше я чекав, поки завершиться збереження документа.

• Нарешті, в правилах безпеки можна та доцільно створювати “зовнішні ключі”, а саме, перевіряти, що повʼязаний документ існує — для цього є функція exists та existsAfter, яка підтримує транзакції. Це теж досить незамінна функція бази даних, особливо такої, де більшість бізнес-логіки міститься на клієнті.