Мы решили эту задачу один раз — на уровне загрузчика коллекций, а не разбрасывая проверки if (isDev) по компонентам.

Зачем нужен единый свап-поинт

Идея простая: у каждой коллекции есть ровно одна функция-источник. Сегодня она читает JSON-фикстуру, завтра — дергает Content API Laravel. Компоненты об этом не знают.

export function contentSource(entity: ContentEntity): Loader {
  if (USE_FIXTURES) {
    return file(`src/content/fixtures/${entity}.json`);
  }
  return contentApiLoader(entity);
}

Почему не просто fetch() в компоненте
Loader выполняется один раз на сборку и результат кешируется Content Layer — на 40 страницах не будет 40 одинаковых запросов.

Что даёт схема Zod

• Ошибка формата ловится в момент astro build, а не после деплоя.
• IDE знает точные поля коллекции — автодополнение работает как для обычного TypeScript.
• Опциональные поля явно помечены — не нужно гадать, может ли значение быть null.

Лучший рефакторинг — тот, который не потребовался, потому что архитектура заранее оставила для него один шов.

из внутренней переписки команды

Что дальше

В следующих раундах мы просто меняем USE_FIXTURES на false и реализуем contentApiLoader() — ни одна страница блога, услуг или проектов не потребует правок.

Ключевые выводы

• Content Layer в Astro 5+ — универсальный интерфейс загрузчика, а не просто обёртка над файловой системой.
• Один «свап-поинт» между фикстурами и реальным API избавляет страницы от условной логики.
• Схема Zod ловит несовпадения формата данных на этапе сборки, а не в рантайме у пользователя.
• Собственный Loader пишется один раз и переиспользуется для всех коллекций проекта.

Частые вопросы

Чем Content Layer отличается от старых Content Collections?

Старые Content Collections были жёстко привязаны к файлам в src/content. Content Layer вводит интерфейс Loader — источником данных может быть файл, API или база, а схема остаётся общей.

Нужно ли переписывать компоненты при смене источника данных?

Нет — если контракт (форма данных, описанная схемой) не меняется, компоненты продолжают работать без правок.

Нужен похожий контур для вашего проекта?
Спроектируем фронтенд так, чтобы бэкенд можно было подключить в любой момент без переписывания страниц.
Обсудить проект

Anatomy ресурса

Один класс Resource описывает форму, таблицу и — через Schemas — сложные составные поля вроде блочного редактора статей.

class PostResource extends Resource
{
    protected static ?string $model = Post::class;

    public static function form(Schema $schema): Schema
    {
        return $schema->components([
            PostForm::make(),
        ]);
    }
}

1. Модель и миграции — как в обычном Laravel-проекте.
2. Policy определяет, кто видит ресурс и какие действия доступны.
3. Schema/Table классы описывают форму и таблицу декларативно.
4. Actions добавляют кастомную логику там, где конфигурации не хватает.

Авторизация — не декорация
Policy проверяется и в UI, и при прямом обращении к модели — скрыть кнопку недостаточно, если политика не защищает сам метод.

Итог: Filament экономит время именно там, где раньше терялись недели — на однотипных CRUD-экранах. Домен-специфичную логику всё равно пишете вы.

Ключевые выводы

• Filament 4 Resource — это декларативное описание формы, таблицы и политики доступа в одном классе.
• Policy-классы Laravel и авторизация Filament работают вместе без дублирования правил.
• Кастомные Actions нужны реже, чем кажется — сначала стоит проверить встроенные.
• Тесты на уровне Resource дешевле, чем ручная проверка каждого релиза.

Когда индекс действительно нужен

• Поле часто участвует в WHERE, JOIN или ORDER BY.
• Таблица достаточно большая, чтобы последовательное сканирование было заметно дороже.
• Селективность высокая — индекс по полю status с тремя значениями почти бесполезен.

EXPLAIN ANALYZE
SELECT * FROM posts
WHERE status = 'published'
  AND published_at <= now()
ORDER BY published_at DESC
LIMIT 12;

Не добавляйте индекс, потому что «так надёжнее». Добавляйте, потому что EXPLAIN это подтвердил.

внутренний код-ревью гайд

Частая ошибка
Композитный индекс (a, b) не используется для запросов только по b — порядок колонок в индексе имеет значение.

Итог простой: сначала EXPLAIN ANALYZE, потом индекс, потом снова EXPLAIN ANALYZE — чтобы убедиться, что план запроса действительно изменился.

Ключевые выводы

• Индекс ускоряет чтение и замедляет запись — добавлять его «на всякий случай» нельзя.
• B-tree подходит для равенства и диапазонов, GIN — для JSONB и полнотекстового поиска.
• EXPLAIN ANALYZE — обязательный шаг перед добавлением индекса, а не после.
• Частичные индексы экономят место, если запросы всегда фильтруют по одному условию.

Техническая база

1. Чистые URL без параметров для основных страниц.
2. Canonical на каждой странице, включая отфильтрованные состояния.
3. BreadcrumbList и FAQPage JSON-LD там, где это уместно.
4. Изображения — только через современные форматы (AVIF/WebP) с явным width/height.

Про Core Web Vitals
LCP, INP и CLS — не абстрактные метрики для отчётов, а прямой фактор ранжирования с 2021 года.

Контент, который решает

Одна статья, отвечающая на реальный вопрос клиента полно и честно, приносит больше трафика, чем десять статей «ниочём» под ключевые слова.

Дальше — вопросы, которые нам задают чаще всего.

Ключевые выводы

• Структурированные данные (JSON-LD) не двигают позиции напрямую, но повышают CTR через rich-сниппеты.
• Скорость первой отрисовки важнее количества ключевых слов на странице.
• Внутренняя перелинковка — самый недооценённый инструмент B2B SEO.
• Уникальный контент побеждает объём: 5 сильных статей лучше 50 сгенерированных.

Частые вопросы

Нужен ли отдельный SEO-специалист на старте проекта?

Нет — на старте важнее правильная техническая база (структура URL, скорость, семантическая разметка); специалист нужен для контентной стратегии позже.

Сколько времени занимает эффект от SEO-правок?

В B2B — от 2 до 6 месяцев, в зависимости от конкурентности ниши и текущего технического состояния сайта.

Влияет ли дизайн на SEO?

Косвенно — через поведенческие метрики (время на сайте, отказы) и Core Web Vitals, которые дизайн и вёрстка формируют напрямую.

Порядок слоёв

1. Токены: цвет, типографика, отступы, радиусы, тайминги анимаций.
2. Примитивы: кнопка, поле ввода, чип, карточка.
3. Композиты: форма, карточка проекта, модальное окно.
4. Паттерны страниц: как композиты складываются в реальные экраны.

Контраст — не опция
Каждая пара «текст на фоне» в токенах должна проходить минимум AA (4.5:1) — иначе доступность придётся чинить точечно на каждой странице.

Документация

Живой пример с переключателем состояний экономит часы созвонов «а как это должно выглядеть при ошибке».

Ключевые выводы

• Дизайн-токены — это первый слой, а не последний штрих: без них компоненты негде переиспользовать согласованно.
• Начинать стоит с 5–7 самых частых компонентов, а не пытаться описать всё сразу.
• Доступность (контраст, фокус-состояния) дешевле заложить в токены, чем чинить постфактум.
• Документация с живыми примерами используется чаще, чем статичный PDF-гайдлайн.

Минимальный набор

• 5 респондентов из целевой аудитории — не коллеги и не друзья.
• Сценарий из 3–5 задач, которые действительно решает продукт.
• Кликабельный прототип, а не финальная вёрстка.

Пользователь не обязан понимать вашу ментальную модель интерфейса. Ваша задача — понять его.

из внутреннего гайда по исследованиям

Видео: https://www.youtube.com/watch?v=dQw4w9WgXcQ

Что делать с результатами

Каждая найденная проблема получает приоритет по формуле частота × серьёзность — это отсекает соблазн чинить редкую, но заметную мелочь раньше системной проблемы.

Ключевые выводы

• Пять пользователей находят около 85% проблем юзабилити — дальше эффект от каждого нового теста падает.
• Модерируемое тестирование дороже, но даёт понимание причины проблемы, а не только её факта.
• Тестировать нужно на прототипе, а не после релиза — иначе исправление обходится в разы дороже.
• Запись сессии важнее финального отчёта — команда должна увидеть проблему своими глазами.

Как устроена декомпозиция

1. Фиксируем цели проекта в терминах бизнеса, не технологий.
2. Раскладываем по модулям: авторизация, каталог, оплата и так далее.
3. На каждый модуль — диапазон часов, а не единственное число.
4. Отдельно считаем риск интеграций с чужими системами.

Почему вилка, а не число
Диапазон в 20–30% честнее отражает неопределённость технического задания на старте, чем ложно точная цифра.

Ключевые выводы

• Оценка без декомпозиции на модули — это гадание, а не расчёт.
• Вилка в смете (а не точное число) честнее отражает неопределённость на старте.
• Технический риск (интеграции, легаси) закладывается отдельной строкой, а не «про запас».
• Оценка пересматривается после первого спринта, когда неопределённость уже ниже.

Задача

Собрать все заявки в одном месте, автоматически распределять их между сервисами по загрузке и не терять ни одного обращения.

Решение

• Единая очередь заявок с автораспределением по загрузке сервиса.
• Синхронизация с 1С по расписанию (каждые 15 минут) вместо вебхуков.
• Уведомления мастеру и клиенту через один и тот же шаблон в разных каналах.

Мы перестали терять клиентов между сервисами — теперь заявка не «зависает» ни в одной тетради.

операционный директор сети

Ключевые выводы

• Единая очередь заявок из всех каналов (сайт, телефония, мессенджеры) убрала «потерю» лидов между менеджерами.
• Автоматическое распределение по загрузке мастеров сократило время до первого ответа клиенту.
• Интеграция с 1С по расписанию, а не в реальном времени, оказалась надёжнее и дешевле в поддержке.
• Отчёты для владельца сети стали ежедневными, а не «раз в квартал в Excel».

Директивы гидратации

<ProjectsGrid client:load categories={categories}>
  <!-- статическая разметка карточек, доступна без JS -->
</ProjectsGrid>
<CaseModal client:idle />

• client:load — гидратация сразу, для критичного интерактива.
• client:idle — когда браузер свободен, для второстепенного интерактива.
• client:visible — при появлении в вьюпорте, лучший вариант по умолчанию.
• client:media — только при совпадении медиа-запроса (например, мобильное меню).

Частая ошибка
client:load на каждом острове «на всякий случай» — самый быстрый способ выйти за бюджет JS на первой загрузке.

Мы проверяем бюджет вручную после каждого раунда: суммарный gzip JS первой загрузки не должен превышать ~70 КБ, из них ~35 КБ — рантайм Vue.

Ключевые выводы

• client:visible откладывает гидратацию до появления в вьюпорте — почти всегда правильный выбор по умолчанию.
• client:load оправдан только для того, что обязано работать сразу же (мобильное меню, критичная форма).
• Общий бюджет первой загрузки стоит проверять руками на каждой новой странице, а не раз в квартал.
• Статическая разметка передаётся в слот компонента — так контент остаётся доступным без JS вообще.

Чек-лист на каждый релиз

1. Все интерактивные элементы доступны с клавиатуры (Tab/Shift+Tab, Enter/Space).
2. Фокус видим и не теряется при открытии/закрытии модалок.
3. Контраст текста — минимум AA (4.5:1 для обычного текста).
4. Изображения имеют осмысленный alt или помечены декоративными.
5. Формы связывают лейбл, поле и текст ошибки через aria-describedby.

Модалки — самое частое место регрессий
Фокус-трап, закрытие по Esc и возврат фокуса на источник — три вещи, которые чаще всего забывают при добавлении нового модального окна.

Этот чек-лист живёт в репозитории рядом с кодом, а не в отдельном документе — иначе про него забывают уже на втором проекте.

Ключевые выводы

• Фокус-состояния должны быть видны на каждом интерактивном элементе, без исключений.
• Модальные окна обязаны ловить фокус и возвращать его на элемент-триггер при закрытии.
• Контраст текста проверяется автоматически в CI, а не вручную перед релизом.
• Скринридер-тестирование хотя бы одного ключевого сценария снимает 90% проблем, незаметных глазами.

Частые вопросы

С чего начать, если аудита доступности никогда не было?

С автоматической проверки (axe-core) на ключевых страницах — это находит примерно треть проблем за один прогон.

Нужен ли скринридер-тест для каждого релиза?

Нет — достаточно для крупных изменений интерфейса; мелкие правки покрывает автоматика и ручная проверка фокуса/контраста.

Хотите бесплатный экспресс-аудит доступности?
Проверим ключевые сценарии вашего продукта по этому чек-листу и пришлём список находок.
Запросить аудит

Что мы фиксируем заранее

export interface PostResource {
  slug: string;
  category: { slug: string; title: string };
  author: { name: string; position: string; same_as: string[] };
  published_at: string; // ISO 8601
}

Зачем типизировать ответ API на фронтенде
TypeScript-интерфейс, синхронизированный с Resource-классом бэкенда, ловит несовпадение полей на этапе компиляции, а не в проде.

Ключевые выводы

• Единая конвенция именования и пагинации экономит часы на онбординге фронтенд-разработчика.
• Ресурсные классы (Laravel API Resources) — естественная точка контроля версии ответа.
• Явные коды ошибок с машинно-читаемым полем важнее «человеческого» текста сообщения.
• Один и тот же формат ответа для фикстур и боевого API избавляет фронтенд от адаптеров.

Какую проблему решают микросервисы

• Независимый деплой разных частей системы разными командами.
• Изоляция отказа одного сервиса от остальной системы.
• Возможность использовать разные технологии под разные задачи.

Микросервисы — это решение проблемы Конвея, а не проблемы производительности.

парафраз известного тезиса в архитектурных обсуждениях

Модульный монолит
Чёткие границы между доменами внутри одного деплоя дают большую часть изоляции микросервисов без сетевых издержек и отдельной инфраструктуры на сервис.

Ключевые выводы

• Микросервисы решают организационную проблему (много команд), а не техническую (нагрузка).
• Модульный монолит с чёткими границами между доменами даёт почти все плюсы микросервисов без сетевых издержек.
• Разделение на сервисы имеет смысл, когда команды физически не могут деплоиться независимо иначе.
• Миграция монолит → сервисы дешевле, чем обратная — начинать с монолита почти всегда безопаснее.

Минимальный набор проверок

1. Зафиксировать гипотезу и метрику успеха до запуска изменения.
2. Посчитать минимальный размер выборки заранее.
3. Смотреть на доверительный интервал, а не только на точечное значение.

Ключевые выводы

• Изменение метрики без проверки статистической значимости — это чаще шум, чем эффект.
• Минимальный размер выборки нужно считать до теста, а не после, глядя на результат.
• Сегментация метрики (по устройству, каналу) часто важнее общего среднего значения.
• Дашборд без контекста (что менялось и когда) провоцирует неверные выводы.