Скелет PHP-проєкту: 5 днів, які не потрапляють у рахунок

Кожен проєкт починається з того самого тижня: репозиторій, завантажувач конфігу, обробник помилок, сторінка входу, міграція для користувачів, три теки, про які ніхто не домовився. Скелет PHP-проєкту перетворює цей тиждень на одну команду, і перший тікет про бізнес-правила приходить на чотири дні раніше.

Код: Atomic-Framework-Application, ліцензія GPL-3.0-or-later.

Скелет це офіційний старт для Atomic Framework, PHP 8.1 або новіше, на тій самій ліцензії GPL:

composer create-project globus-studio/atomic-framework-application myapp
cd myapp
cp .env.example .env
php atomic init/key
php -S localhost:8000 -t public

Що скелет PHP-проєкту замінює першого тижня

Composer підтягує фреймворк, ORM і автозавантажувач. init/key створює ключі шифрування, і це той крок, який команди забувають до першого разу, коли сесія віддає cookie відкритим текстом. Застосунок піднімається на localhost:8000 із вітальною сторінкою, а в репозиторії лежить .env.example зі списком того, що потрібно серверу.

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

Теки кажуть, куди що класти

app/ тримає контролери, моделі, middleware і провайдер користувачів. bootstrap/ тримає константи, завантажувач конфігу й обробку помилок. config/ тримає базу, кеш, пошту, автентифікацію й чергу. routes/ поділений на web.php, api.php і cli.php, тому команда CLI випадково не стає адресою. public/ це корінь сайту з темами й завантаженнями, database/ тримає міграції й сіди, resources/ шаблони, storage/ логи, кеш і сесії.

Список виглядає нудно, і в цьому сенс. Новий розробник відкриває репозиторій і знає, куди покласти файл, не питаючи, а на рев’ю другого тижня вже немає суперечки про структуру.

Автентифікація приходить робочим прикладом

Зі скелетом ідуть три контролери: посадкова сторінка, панель під автентифікацією і вхід із реєстрацією та виходом. Dashboard закритий middleware Authenticate, модель User несе uuid, email, password і role, провайдер читає користувачів із бази, для таблиці користувачів є міграція.

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

Вимоги записані

PHP 8.1 із розширеннями json, session, mbstring, fileinfo, pdo, pdo_mysql і curl. MySQL або MariaDB для даних, Redis рекомендований для кешу, черг, сесій і WebSocket, Composer для залежностей.

Розмова з хостингом потребує цього списку на екрані, і він лежить у README, а не в чиїйсь пам’яті. Половина затримок у першому спринті приходить із відсутнього розширення, а відсутнє розширення коштує звернення в підтримку й перезапуску викладки.

Що перевірити на старті

Три речі ламають першу викладку частіше за інші: .env потрапив у репозиторій, storage/ закритий для запису, міграції не прогнані на сервері. Кожна видна в перші п’ять хвилин, якщо дивитися в правильне місце, і кожна коштує години, якщо дивитися не туди.

Далі черга й розклад. Воркер запускають під supervisor, інакше листи накопичуються в таблиці, і ніхто цього не помічає до першої скарги. schedule/run вішають на cron раз на хвилину, інакше нічний звіт не вийде жодного разу.

Чого скелет не вирішує

Він не вибирає конструктор сторінок, CSS-фреймворк і адмінку. Він не генерує екрани CRUD, а міграції лишаються написаними руками файлами.

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

Скільки це коштує

Година на встановлення й читання тек проти тижня, який більше не з’являється в рахунку. Питання ліцензії те саме, що у фреймворку: GPL-3.0-or-later, що підходить клієнтському сайту й потребує юридичної перевірки для закритого продукту.

Поруч: фреймворк для бізнес-додатків про те, що несе сам фреймворк, і розробка на PHP про те, як рахується обсяг застосунку.