База даних чи Статичний

Довгий час ми жили у світі, де використовуємо стандартні підходи, не замислюючись над їхньою метою. Візьмемо, наприклад, WordPress: це потужний застосунок, але він потребує MySQL як базу даних, а щоб зробити його швидким, часто потрібно Memcache для кешування запитів MySQL і зменшення навантаження на базу даних. Поряд з цим існує WYSIWYG редактор, який, теоретично, дозволяє користувачам легко редагувати HTML, але на практиці часто генерує важкочитабельний та переповнений код.

Але основне питання: чому ми це робимо? Ми встановлюємо WordPress, MySQL і Memcache для того, щоб створити по суті "статичні" сторінки, тому що WordPress може бути повільним, а оновлення контенту зустрічаються рідко. Для кожної згенерованої сторінки:

• Базовий сайт на WordPress робить 10-30 запитів.
• Помірно складний сайт з кількома плагінами та популярною темою: 30-60 запитів.
• Дуже складний сайт з багатьма плагінами та важкими темами може робити 60-100+ запитів.

Навіть проста блог-записка може вимагати від 10 до 100+ запитів, що пояснює, чому сайти на WordPress можуть бути повільними.

Чому Ми Обираємо WordPress?

Головне питання залишається: Чому ми використовуємо такий складний механізм? Історично, використання реляційної бази даних, як MySQL, для блогу мало сенс, тому що люди могли залишати коментарі, а бази даних надавали швидкий спосіб зберігати і отримувати цю інформацію. Але сьогодні мало які сайти на WordPress мають увімкнені коментарі через нескінченний потік спаму, який часто з цим пов'язаний. Як результат, більшість сайтів покладаються на сторонні рішення, такі як Disqus або Facebook Коментарі для управління коментарями користувачів. Ці сервіси беруть на себе верифікацію користувачів і фільтрацію спаму, що означає, що нам більше не потрібна база даних для обслуговування динамічного контенту у вигляді коментарів.

Статичний Підхід

У True ми обрали повністю статичний підхід. Ми використовуємо статичні файли як нашу "базу даних":

• blog.php обробляє сторінки блогу.
• support.php обробляє сторінки підтримки (історично різні, але тепер схожі за форматом).
• categories.php обробляє список категорій у верхньому меню та боковій панелі.

Ми зберігаємо весь блог як прості файли PHP або JSON, що є ефективним, оскільки ми використовуємо PHP для запуску нашого сайту.

Ось як це працює:

Кожен запис блогу зберігається як папка, що містить файл у форматі markdown (_.md) та пов'язані ресурси, такі як зображення та вкладення.

У нас також є два додаткові папки для:

• Translate: Зберігає переклади файлів markdown на різні мови (наприклад, es_ES, de_DE).
• HTML: Містить згенеровані HTML файли з markdown, які генеруються знову при кожному розгортанні.

Магія відбувається під час процесу розгортання. Ми використовуємо Composer, щоб ініціювати перетворення з markdown у HTML за допомогою скриптів:

"scripts": {
    "post-install-cmd": [
        "php bin/markdown-to-html.php"
    ],
    "post-update-cmd": [
        "php bin/markdown-to-html.php"
    ]
}

Найкращим інструментом для перетворення markdown, який ми знайшли, є league/commonmark, який має корисні плагіни, включаючи підтримку таблиць і власні шляхи до CDN для наших зображень.

Розгортання

Ми використовуємо процес розгортання на основі GitHub Actions та Deployer, яке було легко інтегрувати. Ось приклад скрипта:

name: Deploy
on:
  push:
    branches: [ "main" ]
concurrency: production_environment
jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"

      - name: Deploy
        uses: deployphp/action@v1
        with:
          private-key: ${{ secrets.PRIVATE_KEY }}
          dep: deploy
          verbosity: -vvv

Процес простий: кожен раз, коли хтось робить комміт у гілку "main", розгортання відбувається автоматично. Дії під час розгортання включають:

1. Копіювання зображень у папку public/img.
2. Генерацію хеш-карти для всіх зображень та вкладень.
3. Генерацію HTML з markdown файлів з: • Виправлення шляхів до зображень (наприклад, з /img/blog/... до cdn.truesocialmetrics.com/img/blog/...). • Оновлення шляхів до CDN, де це потрібно.

Під час генерації HTML також додаються макети, заголовки та меню. Так ми забезпечуємо статичні файли, що можуть здаватися динамічними користувачам.

Переваги Статичного Підходу

Продуктивність

Статичні сайти надзвичайно швидкі, з часом завантаження сторінки всього 3-5 мс.

Простота

Навчити нашу команду підтримки використовувати Markdown набагато простіше, ніж навчити їх навігації в складному CMS, як WordPress.

Чистий Код

Контролюючи процес перетворення markdown у HTML, ми забезпечуємо чистоту та оптимізацію HTML для пошукових систем (привіт, Google!) та функцій, як "Режим читача" у браузерах.

Підтримуваність

Оскільки ми використовуємо статичні файли та Git для контролю версій, кожна зміна відслідковується автоматично, навіть до окремих рядків. Вкладення, такі як зображення, також виграють від контролю версій, тому ми завжди знаємо, хто вніс зміну і чому. Це робить пошук і модифікацію контенту ефективними, використовуючи інструменти, такі як grep і ack.

Доступність для Команди

Наша команда знаходить статичну структуру легкою в роботі, особливо з такими інструментами, як GitHub Desktop та Typora, простий і гарний редактор markdown.

Висновок

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