Англійська для розробників Supabase

Supabase стала широко використовуваною альтернативою Firebase з відкритим кодом, надаючи розробникам повний набір баз даних Postgres з автентифікацією, зберіганням і функціями реального часу. Якщо ви працюєте з Supabase у міжнародній команді, вам знадобиться точна англійська мова для опису правил бази даних, поведінки у реальному часі і функцій краю. Цей підручник містить основні словники для розробників Supabase.

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

** Безпека на рівні рядків (RLS) ** — це функція Postgres, що є центральною для моделі безпеки Supabase, яка обмежує, які рядки користувач може читати або записувати на основі правил. “Ми ввімкнули безпеку на рівні рядків у таблиці orders, тому користувачі можуть бачити тільки свої власні замовлення, а не замовлення інших.”

** Policy ** — правило, яке прив’ язано до таблиці у RLS, яке визначає, хто може виконувати які дії у яких рядках. “Ми написали правила, які дозволяють SELECT тільки тоді, коли auth.uid() = user_id.”

** Підписка у реальному часі ** — функція, яка надає змогу клієнтам отримувати оновлення у реальному часі, коли рядки у таблиці вставляються, оновлюють або вилучаються.

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

** Edge function ** — безсерверна функція, написана на Deno, яка виконується поруч з користувачем і може бути викликана за допомогою HTTP або за допомогою подій бази даних.

• “Ми пересунули наш обробник webhook у функцію краю, щоб він автоматично масштабувався без керування серверами.” *

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

** Анонімний ключ ** — відкритий ключ API, який використовується клієнтськими програмами, безпечний для виявлення, доступ до якого повністю обмежено правилами RLS. “Ключ anon вбудований у наш пакет інтерфейсу, але це нормально — правила RLS намагаються забезпечити те, що він може робити насправді.”

** Storage bucket ** — контейнер для зберігання файлів (зображень, документів тощо) з власними правилами доступу, подібними до RLS для таблиць.

• “Ми створили публічне сховище для аватарів і приватне сховище для документів користувача, кожне з яких має різні правила доступу.” *

** Функція / тригер Postgres ** — логіка SQL, збережена у базі даних, яка може бути використана знову і знову, часто використовується для впровадження бізнес- правил або автоматизації побічних ефектів змін даних.

• “Ми написали тригер Postgres, який автоматично оновлює стовпчик updated_at при кожній зміні рядка.” *

** Database webhook ** — функція Supabase, яка викликає зовнішню кінцеву точку HTTP кожного разу, коли відбувається вказана подія бази даних. “Ми використовуємо webhook бази даних для повідомлення нашої служби розрахунків про те, що рядок підписки було оновлено.”

Розглядається питання про безпеку та політику

• «Ми тестуємо кожну політику RLS зі скриптом, який запускається як різні користувачі, щоб переконатися, що ніхто не може випадково прочитати дані іншого користувача»
• «Ключ ролі сервісу повинен використовуватися тільки в коді на стороні сервера — якщо він витікає, політика ізоляції нічого не означає»
• «Ми перевірили всі наші правила після майже промаху, коли політика використовувала USING (true) помилково, виставляючи кожен рядок»

Розмовляємо про реал-тайм і Edge-функції

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

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

1. ** Завжди пояснюйте RLS з точки зору ризику, який він запобігає. ** « Без цієї політики, будь- який користувач міг би запитати приватні дані будь- якого іншого користувача » робить ставки ясними для рецензентів.
2. ** Ніколи не приймайте ключ anon за безпечний за типовим налаштуванням. ** Його безпека повністю залежить від правильно написаних правил RLS — вкажіть це у документації.
3. ** Реєструвати спроби відмови у виконанні правил під час тестування. ** Простіше пояснити « це правило заблокувало неавторизоване читання », ніж зневаджувати порожній набір результатів.

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

1. Поясніть новому члену команди 3- 4 реченнями різницю між ключем anon і ключем ролі service.
2. Напишіть коротке пояснення (4- 5 речень) щодо того, що робить безпека рівня рядка і чому вона важлива для програми з декількома користувачами.
3. Опишете, простою англійською, ваду, яку ви знайшли, коли правила були занадто допустимими, і як ви її виправили.

Розвиток мовлення: вивчення мовлення в контексті мовлення

Ядро ефективного спілкування як розробника полягає не лише в тому, щоб знати що сказати, але і як сказати це. Для не-англомовних носіїв англійської мови, особливо тих, хто вступає в світ Supabase і його пов’язаних технологій - безпека на рівні рядків, підписки в реальному часі, краю функції, і Postgres політики - освоєння професійного англійського словника може відчувати, як масштабування складної бази даних самої. Це розуміння тонких відмінностей у фразуваннях, що впливають на ясність, точність і, врешті-решт, успішну співпрацю в команді. Одним з найпоширеніших викликів є різниця між простою заявою про вимогу і її вираження як добре визначеної специфікації. Розглянемо це повідомлення Slack:

«Відкрийте ворота»

Хоча технічно це правильно, у нього немає важливого контексту. Більш вишуканим підходом було б: « Чи можете ви дослідити проблему з аутентифікацією користувача, яка періодично зазнає невдачі під час пікового навантаження? Зокрема, я бачу збільшення затримки в підписках в реальному часі, пов’язаних з потоками активності користувачів. Давайте визначимо пріоритет зневадження цього в рамках реалізації політики Postgres для таблиці users. ” Подивіться, наскільки більше інформації передається — не тільки * що *, але також * чому * і * вплив *. Цей рівень деталізації є важливим під час обговорення технічних питань з колегами, створення описів запитів на звантаження або участі у перегляді коду.

Крім того, розуміння мови, використовуваної в коментарях перегляду коду, є критичним. Отримання коментаря на зразок « Цей запит неефективний » може бути розчаруванням, якщо ви не розумієте його логіку. Це може бути надто широке SELECT *, відсутність належного індексування або неоптимальний використовування функцій Postgres. Навчання відповідати такими фразами, як «Я розгляну потенційні поліпшення індексу» або «Давайте проаналізуємо план виконання запиту» демонструє розуміння і бажання співпрацювати з оптимізацією - ключова навичка в будь-якому середовищі розробки. Це про перетворення критики в спільні зусилля щодо кращого коду.

Нарешті, не недооцінюйте важливість точної термінології при описі вашої роботи в описах PR. Замість того, щоб сказати « Я поліпшив безпеку », поясніть * як * ви поліпшили безпеку. « Впроваджено правила безпеки на рівні рядків за допомогою функцій Postgres для обмеження доступу за допомогою ролей користувачів і прав доступу у таблиці products », це набагато більш інформаційний текст, який демонструє глибше розуміння можливостей Supabase.

supabase db.functions.create_policy('products', 'read', {
  data: {
    fields: ['*']
  },
  user_relation: 'users'
})

У цьому прикладі показано основну структуру створення правила Postgres у Supabase, а також показано, яким чином цей специфічний словник буде використано для опису покращень безпеки.