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

Gatsby популяризував витягування вмісту з будь-якого джерела в об’єднаний шар GraphQL і попереднє відтворення його в статичний HTML - шаблон, який багато нових фреймворків прийняли по-своєму. Якщо ви підтримуєте існуючий сайт Gatsby або ви переходите на нього, ви зіткнетеся з словником, який є специфічним для архітектури Gatsby: додатками джерела, шаром даних і його різними режимами відтворення. Цей посібник містить умови.

---

Шар даних GraphQL

** Шлях даних ** — внутрішній API GraphQL Gatsby, який об’ єднує вміст з кожного налаштованого джерела (файли markdown, CMS, API) у одну схему, яку можна запитати. “Замість написання окремої логіки отримання для нашої CMS і наших локальних файлів markdown, ми запитуємо обидва через шар даних Gatsby з одним запитом GraphQL.”

** Додаток джерела ** — додаток, який витягує дані з певного джерела (файлової системи, Contentful, REST API) до шару даних GraphQL.

“Ми використовуємо gatsby-source-filesystem для наших постів з зниженням ціни і gatsby-source-contentful для наших маркетингових сторінок — обидва запитуються через ту ж саму схему GraphQL.”

** Додаток перетворення ** — додаток, який перетворює необроблені дані джерела у більш корисну форму, наприклад, перетворює необроблені дані маркування у HTML AST, який можна використовувати у інших додатках або запитах.

” gatsby-transformer-remark отримує необроблений код з нашого додатка і аналізує його, щоб ми могли запитати відтворений HTML безпосередньо у GraphQL.”

** Запит сторінки проти статичного запиту ** — ** запит сторінки ** виконується на верхньому рівні шаблона сторінки і може приймати змінні (наприклад, слуг); ** статичний запит ** виконується всередині будь- якого компонента, але не може приймати змінні.

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

---

Збудувати і відтворити словник

« gatsby- node. js »

Файл ** gatsby-node.js ** — це файл, у якому ви створюєте сторінки за допомогою програмування під час збирання — зазвичай, це циклічне перенесення даних з шару GraphQL і виклик createPage для кожного елемента.

“Кожна сторінка блогу створюється в gatsby-node.js — ми запитуємо всі пости, перевертаємо їх, і викликаємо createPage один раз на один слиз.”

Інкрементальні збирання

** Приростові збирання ** перебудовують лише ті сторінки, на які впливає зміна вмісту або коду, замість того, щоб кожного разу перебудовувати весь сайт з нуля.

“До послідовних збирань, виправлення однієї помилки означало двадцять хвилин очікування на повне перебудування — тепер перебудовується лише невелика кількість сторінок, які були втрачені.”

Сервер-Стороннє Відтворення (SSR) в Gatsby

Gatsby підтримує ** SSR ** для певних сторінок, які потребують відтворення нових даних за запитом, поряд з типовим статичним генеруванням для всіх інших.

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

Відкладене статичне покоління (DSG)

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

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

---

Плагіни і екосистема

** gatsby-config.js ** — центральний файл налаштувань, у якому оголошуються додатки джерела, метадані сайту та інші додатки.

** Конвейєр обробки зображень ** — вбудована система Gatsby (gatsby-plugin-image і її попередники) для створення адаптивних, оптимізованих варіантів зображень під час збирання.

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

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

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

---

Міграція та еміграція

** Content mesh ** — більш широка ідея, популяризована Гетсбі, що стосується складання вмісту з декількох відокремлених джерел на одному сайті, а не покладатися на одну монолітну CMS.

“Наша мережа контенту витягується з трьох різних систем — старої CMS, безголової CMS для нового контенту, і локального markdown для документації — всі об’єднані через шар даних Gatsby.”

** Міграція фреймворку ** — перенесення існуючого сайту Gatsby на новіший мета- фреймворк, часто з причини скорочення часу збирання або скорочення екосистеми додатків.

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

---

Розробка архітектури гетсбі для команди

Situation	Phrase
Explaining the data layer to a new hire	”Everything — CMS content, markdown files, even our team roster spreadsheet — gets pulled into one GraphQL schema, so every page template queries data the same way.”
Justifying incremental builds	”A content-only change now rebuilds in under a minute instead of twenty, because incremental builds only touch the pages affected by that change.”
Explaining a rendering mode choice	”The dashboard page uses SSR because its content is per-user — everything else stays statically generated for speed.”
Discussing a migration decision	”We’re not migrating because Gatsby is broken — it’s that our plugin ecosystem has stagnated and build times have grown past what we’re comfortable with.”

Поширені помилки

• Назвавши кожен запит Gatsby «статичним запитом» — тільки запити без змінних кваліфікуються; запити рівня сторінки зі змінними є окремою концепцією.
• Сказати «Gatsby це просто статичне створення сайту» без згадки про підтримку SSR і DSG — фреймворк підтримує більше режимів відтворення, ніж чистий SSG.
• Посилаючись на gatsby-node.js як на «backend» — він запускається під час збирання для створення сторінок, а не як сервер виконання.

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

1. Поясніть у двох реченнях різницю між додатком для створення коду і додатком для перетворення.
2. Написати короткий коментар до файла gatsby-node.js, у якому пояснюється, чому для певного типу сторінки використовується DSG замість повного статичного створення.
3. Написати коротке резюме (3- 4 речення), у якому буде обґрунтовано рішення про перенесення сайту Ґетсбі на іншу мета- платформу.

Зв’язані ресурси

• Англійська для розробників Docusaurus
• Англійська для Eleventy (11ty) Developers
• Словник API: REST, GraphQL, gRPC

На практиці: Навігація Nuance - Відгуки і співпраця

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

Розглянемо сценарій: Сара, молодший розробник, яка приєднується до команди, що підтримує великий сайт Gatsby, отримує цей коментар щодо запитів на завантаження, що вводять новий компонент, який отримує дані з GraphQL: « Цей запит неефективний; перефрактуруйте його для кращої продуктивності ». Хоча це технічно правильно — запит дійсно можна оптимізувати — йому бракує контексту. Вона не пояснює * чому * вона неефективна (наприклад, надто багато полів, що отримуються, відсутність сторінкування) або пропонує конкретні поліпшення. Кориснішим варіантом відповіді буде: « Цей запит отримує всі дані користувача, що може вплинути на час завантаження сторінки. Розгляньте реалізацію сторінкування, щоб обмежити кількість повернених результатів і отримати тільки необхідні поля - конкретно id і name. Ви можете досягти цього, додавши first: 100 до ваших аргументів GraphQL.” Ключовим тут є надання конкретних рекомендацій разом з критикою.

Інша поширена проблема виникає в описах PR, де розробники повинні чітко сформулювати свої зміни для рецензентів. Нечіткого опису, наприклад, « Виправлена помилка », недостатньо. Замість цього хорошим описом буде: “Розв’язана проблема, коли компонент зображення не відображався правильно на мобільних пристроях через недостатню чутливість стилю. Додано медіа-запити для коригування розмірів зображення на основі розміру екрана і реалізовано max-width: 100% для запобігання переповнення. “Цей рівень деталізації забезпечує, що рецензенти розуміють проблему, рішення і обґрунтування за ним - вирішальне для прийняття і інтеграції в базу коду. Сфокусування на тому, що змінено, чому це було необхідно і як це впливає на загальну систему, є надзвичайно важливим.

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

gatsby develop --inspect # Example Gatsby CLI command to help debug issues