Англійська для Firebase

Firebase переміщує багато того, що раніше було бекендовим кодом в конфігурацію - правила безпеки замість логіки авторизації API, слухачі замість опитування кінцевих точок - і цей зсув потребує власного словника, щоб обговорити чітко, замість нав’язування традиційних бекендових термінів на іншу модель.

Ключовий словник

** Правила безпеки ** — декларативний набір правил, що визначає, хто може читати або записувати які документи у Firestore (або базі даних у реальному часі), які застосовуються на стороні сервера незалежно від того, що намагається зробити клієнтська програма. “Ця витік даних не був помилкою клієнта — правила безпеки дозволяли будь-якому автентифікованому користувачеві читати будь-який документ користувача, а не тільки свій власний.”

** Прослушка у реальному часі ** — підписка на документ або запит, який автоматично надсилає оновлення до клієнта кожного разу, коли змінюються дані, без проведення опитування або отримання даних з боку клієнта. “Ми не маємо потреби оновлювати цей екран вручну — у цьому документі є слухач у реальному часі, отже, він оновлюється негайно, як тільки інший користувач змінює дані.”

** Collection ** — група документів у Firestore, приблизно аналогічна таблиці у реляційній базі даних, але без схеми, кожен документ може мати свій набір полів. “Ми зберігаємо кожен замовлення як свій власний документ у збірці orders — немає фіксованої схеми, тому рядкові елементи можуть змінюватися між документами без міграції.”

** Cloud Function ** — код на стороні сервера, який виконується у відповідь на подію (запис документа, запит HTTP, запланований тригер) без безпосереднього керування командою будь- якої серверної інфраструктури. “Підтвердження електронною поштою надсилається за допомогою хмарної функції, яка запускається автоматично кожного разу, коли створюється новий документ у збірці orders — окремої служби обробки цього не існує.”

** Денормалізація ** — навмисне дублювання даних у декількох документах (замість посилання на них), щоб уникнути дорогих з’ єднань, звичайний шаблон Firestore, оскільки у ньому немає підтримки зв’ язків. “Ми денормуємо ім’ я автора безпосередньо на кожному документі повідомлення — Firestore не може ефективно об’ єднувати збірки, тому дублювання цього поля уникає додаткового читання за повідомлення.”

Звичайні фрази

• Чи правила безпеки насправді дозволяють це, або це баґ?»
• Чи використовує цей екран слухач у реальному часі, чи це просто отримання одного разу?»
• «Яка колекція належить до цього документа?»
• Чи є ця логіка в хмарній функції, чи вона все ще на стороні клієнта?»
• Чи ми денормуємо це поле, чи ми робимо декілька читання, щоб отримати його?»

Приклади висловлювань

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

Пояснення механізму оновлення інтерфейсу користувача: “Дисплею не потрібна кнопка оновлення, оскільки він побудований на слухачі реального часу — в момент зміни основного документа, Firestore відсилає оновлення і інтерфейс користувача автоматично перевідображається.”

Опис рішення щодо схеми у перегляді проекту: “Ми денормуємо назву та ціну продукту на кожен рядок замовлення у час запису — оскільки Firestore не підтримує з’єднання, повторное отримання документа продукту для кожного рядка на кожному читанні замовлення буде дорогим.”

Професійні поради

• Завжди перевіряти ** правила безпеки ** незалежно від перевірок на стороні клієнта під час перегляду — код клієнта можна повністю обійти, отже правила є фактичним шаром виконання, а не резервною копією цього шару.
• Скажіть ** real-time listener **, а не « auto- refresh », коли пояснюєте оновлення інтерфейсу користувача — це називає фактичний механізм і сигналізує, що ви розумієте, що це засновано на відсиланні, а не на опитуванні.
• Посилайтеся на конкретну назву ** збірки ** під час обговорення моделі даних — « документи » є неоднозначним, якщо програма має більше ніж одну збірку з подібною формою.
• Обґрунтуйте денормалізацію явно з шаблоном читання, якого вона уникає — це навмисний компроміс, і зазначення причини запобігає тому, щоб хтось пізніше «виправив» його в дорогий шаблон, схожий на з’єднання.

Практичні вправи

1. Напишіть речення, у якому пояснюється, чому правила безпеки важливі навіть при впровадженні перевірки на стороні клієнта.
2. Пояснити, що виконує слухач у реальному часі, відрізняючись від опитування.
3. Опишемо ситуацію, у якій денормалізація поля у Firestore має сенс.

На практиці: Навігація та співпраця

Погляньмо правді в очі - професійний розвиток не завжди є сонячним світлом і веселками. Частиною освоєння будь- якої мови, особливо під час вивчення технічного словника, є розуміння того, як цей словник * насправді * проявляється у повсякденній взаємодії з вашою командою. Як людина, для якої англійська не є рідною мовою, працюючи над проектами Firebase, ви, ймовірно, зіткнетеся з ситуаціями, в яких точне формулювання робить всю різницю між гладкою співпрацею і розчаруваннями. Це не просто про те, щоб знати визначення «правила безпеки» або «слухача в реальному часі»; це про те, щоб сформулювати * чому * щось робиться, * як * це впливає на інших, і пропонує конструктивний зворотній зв’язок ефективно.

Розглянемо наступний сценарій: Ви переглядаєте запит на збирання нової функції, яка використовує слухачів Firebase Realtime Database. Ваш колега, назовемо його Девідом, реалізував логіку слухача безпосередньо у функції без будь- якого оброблення помилок або обмеження швидкості. Під час перегляду коду вам слід пояснити, * чому * це є проблемою і запропонувати рішення. Просто сказати “Це потрібно виправити” не впорається. Замість цього ви можете сказати: « Девід, я ціную прогрес у цій функції. Однак, відкриття слухача бази даних реального часу безпосередньо для вводу користувача без надійної обробки помилок вводить потенційні вразливості. Нам потрібно переконатися, що ми грациозно управляємо неочікуваними типами даних або надмірними запитами, які можуть перевантажити базу даних. Можливо, додавання блоку try...catch навколо ініціалізації слухача і реалізація деяких основних обмежень швидкості були б корисними - щось на зразок обмеження запитів на основі IP-адреси. “Зауважте ретельну фразу: визнання його зусиль, чітке зазначення ризику (“вразливості”, “перевантаження”), запропонування конкретних рішень (“надійне оброблення помилок”, “обмеження швидкості”) і використання умовної мови (“можливо”).

Інша поширена ситуація виникає в каналах Slack, де обговорюється звіт про помилку. Користувач повідомляє про періодичні проблеми з синхронізацією даних після оновлення. Розмова може початися з неясних скарг, таких як: «Це не працює!» або «Дані зіпсовані!». Вам нужно реагировать спокойным и систематическим образом, собирая информацию и предлагая возможные причины. Замість того, щоб реагувати емоційно, ви можете сказати: «Гаразд, давайте розслідуємо це далі. Можете описати обставини, що призвели до цього питання? В частности, какие действия были предприняты непосредственно перед появлением расхождений в данных? Нам слід перевірити, чи є якісь зміни у наших правилах безпеки, які можуть впливати на контроль доступу, або чи можемо ми визначити потенційну умову перегонів, пов’ язану з одночасними оновленнями. Давайте також переглянемо журнали бази даних у реальному часі на предмет повідомлень про помилки». Це демонструє професіоналізм і направляє розслідування до розв’ язання проблеми.

Ось приклад, який показує, як ви можете використовувати правила безпеки Firebase у описі PR:

rules_version = '2';
 isSignedIn {
  request.auth.uid == 'user-id' // Ensure only authenticated users can access data
}

// Allow read access to specific collections for authorized users
allow read: if request.resource.name == 'users/profile'

У цьому фрагменті правила чітко вказано мету — автентифікацію і контроль доступу до певної збірки — що набагато більш інформаційно, ніж просто « Потрібні правила безпеки ». Метою є не просто написати правила, а пояснити їх мету і логічне обґрунтування у ширшому контексті проекту.