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

Розмови Blitz.js, як правило, зосереджені на захисті своєї моделі «zero-API», де код фронтенду викликає функції бекенду безпосередньо без написаних вручну кінцевих точок REST або GraphQL, тому словник включає запити, мутації і те, як фреймворк приховує межі мережі.

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

Zero-API layer — підхід Blitz.js, що дозволяє компонентам React імпортувати і викликати функції бекенду безпосередньо, з фреймворком, який прозоро перетворює ці виклики в мережеві запити за кадром. “З нульовим API-рівнем, ви не підтримуєте окрему кінцеву точку REST для кожної мутації — компонент просто імпортує функцію і викликає її так, ніби вона локальна.”

Query resolver — функція backend Blitz.js, що розташована разом зі сторінками, які її використовують, відповідальна за отримання і повернення даних, автоматично підключена до React Query на фронтенді. “Цей розв’ язувач запитів вже обробляє кешування через React Query — вам не потрібно додавати власну логіку отримання і кешування в компонент.”

** Mutation resolver ** — функція сервера Blitz. js, яка виконує дію запису (створення, оновлення, вилучення) і може бути викликана безпосередньо з компонента клієнта з автоматичним завантаженням і станами помилок. “Оберніть обробник кнопок навколо цього розв’ язувача мутацій — Blitz надає вам безкоштовно стан очікування, отже вам не потрібен власний прапорець isSubmitting.”

** Колокаційна * - конвенція Blitz.js з розміщення файлів розв’язувачів бекенду всередині тієї ж теки функцій, що і сторінки фронтенду, які їх споживають, замість розділення фронтенду і бекенду на окремі каталоги верхнього рівня. “Зважаючи на колокацію, розв’ язувач для цієї сторінки знаходиться поруч з нею в тій же самій теці — вам не потрібно полювати через окреме дерево api/.”

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

• “Додати захист сеансу до конвеєра розв’ язувача замість перевірки прав вручну всередині функції — таким чином кожен користувач цього розв’ язувача отримає однаковий захист.” *

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

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

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

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

Перегляд структури файла:

• « Через колокацію, цей розв’ язувач слід пересунути поряд зі сторінкою, яка його використовує, а не залишити у загальній теці сервера. » *

Пояснення коментарів щодо перегляду безпеки: “Покласти перевірку власника у трубку розв’ язувача, а не у верхню частину функції — так її буде застосовано послідовно і легше буде її перевіряти.”

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

• Використовуйте zero-API layer, щоб пояснити, чому в коді немає видимого контракту REST або GraphQL — це запобігає заплутаним пошукам визначень кінцевих точок.
• Розрізняти ** розв’ язувач запитів ** і ** розв’ язувач мутацій ** у коментарях перегляду, оскільки вони мають різну поведінку кешування і анульування у React Query.
• Посилання ** colocation **, коли пояснюється структура тек розробникам, які звикли до жорсткого розділення інтерфейсу/ сервера — це змінює те, де вони повинні очікувати знайти речі.
• Рекомендується централізувати перевірки у ** конвеєрі розв’ язання ** під час перегляду безпеки, оскільки розкидані ручні перевірки прав доступу важче контролювати послідовно.

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

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

Навігація та зв’язок

Будьмо чесними - перегляд коду не завжди є сонячним і веселим. Вони можуть відчувати себе критичними, навіть якщо це не є їхнім намір. Як розробник Blitz.js, особливо коли працюєш з глобальною командою, чітке і конструктивне спілкування є абсолютно необхідним. Мета не в тому, щоб зруйнувати вашу роботу, а допомогти вам створити щось краще — швидше. Думай про це не як про суд, а як про спільне дослідження.

Одна спільна область для тертя виникає при поясненні філософії «нуль-API». Розробники, не знайомі з цим підходом, можуть запитати: «Чому ми не використовуємо традиційний API?» Добра відповідь виходить за рамки простого вказівок на переваги; вона формує обговорення навколо спільного розуміння. Замість оборонного пояснення, спробуйте щось на зразок: “Я розробив цей резольвер для безпосереднього доступу до шару даних, мінімізуючи зовнішні залежності і зменшуючи потенційні точки невдачі - подумайте про це як про спрощення нашого потоку і спрощення зневадження. Ми можемо обговорити, як це впливає на налаштування вашого компонента, якщо ви хочете дослідити альтернативні підходи. “Цей підхід визнає їхню точку зору, поки вони ніжно ведуть їх до основних принципів. Аналогічно, при обговоренні змін в описі Pull Request, уникайте жаргону, наприклад, «оптимізації розв’язувачів» - замість цього, будьте чіткими: «Рефакторизований розв’язувач X для поліпшення швидкості отримання даних і зменшення затримки за допомогою пакетних операцій. Ця зміна відповідає нашій стратегії нульового API, мінімізуючи прямі взаємодії з базами даних. ”

Інша ключова фраза, яку ви почуєте, це «розв’язувачі». Хоча сам термін може здатися абстрактним, важливо пояснити їх роль в контексті Blitz.js — вони діють як посередники між вашими компонентами React і базовим шаром даних. Коли ви пояснюєте це комусь, хто не знайомий з фреймворком, розгляньте такі фрази: «Розв’язувачі по суті є функціями, які отримують дані з нашого шару даних на основі запиту компонента. Вони є ключовим зв’язком, що забезпечує, що ми витягуємо тільки те, що потрібно, коли це потрібно, що є ключем до підтримки високопродуктивної і масштабованої програми. “Ключеве значення має пам’ятати, щоб завжди пов’язувати це з більшою картиною - як це впливає на загальну архітектуру?

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

// Example Blitz.js Resolver (Illustrative) - demonstrating data layer access
// This is NOT a fully functional resolver but demonstrates the concept
const fetchData = async (query) => {
  try {
    const result = await blitz.data.resolvers.user.get({ id: query }); // Accessing a data layer resolver
    return result;
  } catch (error) {
    console.error("Error fetching user:", error);
    throw new Error("Failed to fetch user data");
  }
};