Чем заниматься в новогоднюю ночь – дело фантазии каждого. Может кому-то нравится в это время деплоить...

Если под утро вам вдруг станет грустно, то можете провести это время с пользой и через Ansible поднять свой локальный кэширующий прокси-реестр DockerHub для своего Jenkins :)

Каникулы проведены с пользой. На них занялся уборкой:

Исправил опечатки в коде аукциона по issues. Доработал некоторые эпизоды: улучшил команду deploy в эпизоде о Jenkins, перешёл везде на вызов docker-compose build с флагом --pull, кое-где сократил длинные вступления и подведения итогов.

Видеоролики тоже исправлены и перезалиты.

Скринкастов на сайте уже стало много. Свои комментарии под ними искать не очень удобно.

Чтобы вы больше не теряли свою переписку с полезными вопросами и ответами в кабинете теперь есть ссылка "Мои комментарии":

https://deworker.pro/cabinet

А в ближайшем эпизоде напишем полноценную инфраструктуру Feature Toggles к фронтенду и бэкенду для более удобной разработки по принципам CI/CD.

Многие из вас интересовались, какая цветовая схема для PhpStorm используется в наших скринкастах. Тема сделана вручную специально для скринкастов. Делимся ей в нашем новогоднем дайджесте.

Новый мегаэпизод готов!

При рассмотрении философий CI/CD мы вместо Feature Branches говорили о подходе Trank Based Development для скрытой разработки новой функциональности в основной Git-ветке.

Сегодня это сделаем на практике. Добавим к проекту инфраструктуру полноценной работы с Feature Flags для фронтенда на ReactJS и бэкенда на PHP.

И при разработке компонента для бэкенда рассмотрим и применим принцип ISP из SOLID.

Если мы ведём разработку всего проекта в одном монорепозитории, то сталкиваемся с неудобством долгого запуска pipeline. При малейшей правке файлов фронтенда у нас запускаются линтеры и тесты для всего проекта, а не только для фронтенда.

Сегодня мы оптимизируем наш Pipeline в Jenkins так, чтобы он запускал проверки только для изменённого кода. Для этого научим его пользоваться командами git diff и docker-compose images для отслеживания изменений кода и софта. При этом рассмотрим нюансы, с которыми можно столкнуться при внедрении такой автоматизации.

В нашем коде мы активно используем контейнер внедрения зависимостей для работы с сервисами. Но мы с вами мало внимания уделяли практикам написания самих сервисов. Этому я решил посвятить следующую большую подробную статью своём блоге @elisdnru

Но перед этим нужно разобраться с определениями, которые мы будем там использовать. Чтобы потом было понятнее. Поэтому сегодня рассмотрим, что в нашем коде чем является с точки зрения ООП.

В личном блоге опубликовал импровизированный стрим на общеполезные темы:

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

Репостить статьи и видео с сайта elisdn.ru здесь больше не буду. Для них рекомендую подписаться на канал @elisdnru. Там помимо стримов скоро выйдет вторая мега-статья про практики внедрения зависимостей.

А пока мы записываем и монтируем свежие видео для серии Slim & React про подключение маршрутизации и работу фронтенда с API в форме регистрации. Так что до встречи в следующих скринкастах 👍🏼

Продолжаем разработку проекта.

Чтобы было где размещать формы регистрации и входа нам понадобятся новые страницы.

Поэтому сегодня вынесем общий шаблон вёрстки, установим маршрутизатор и с помощью Feature Flag добавим страницу для формы регистрации.

А перед этим заодно доустановим линтеры для Jest-тестов и доработаем E2E-тесты для возможности работы с асинхронными страницами и добавления тестов до кода.

Осторожно, много кода и тестов :)

Сегодня сделали форму регистрации со страницей подтверждения. Организовали работу React с API. Добавили вывод доменных ошибок и ошибок валидации для полей. Отрефакторили код и вынесли клиент для работы с API. Сделали проксирование запросов с фронтенда на бэкенд. Добавили защиту от повторных кликов и вынесли компоненты для элементов формы для использования в других формах.

С фронтендом мы разобрались. Пора переходить к разработке API-бэкенда. Сегодня переведём API на PHP 8.0. Перейдём на сборку PHP-расширений в Dockerfile напрямую из исходников вместо использования PECL. Пропишем новые нативные типы. Также упростим PHPDoc-блоки за счёт перехода от Psalm-аннотаций на классические и за счёт удаления повторов.

Многие спрашивали, почему мы проверяем свой код только на соответствие PSR-12, но не следим за другими нюансами и не используем популярный подход final or abstract для написания классов.

Сегодня как раз это и сделаем. Перейдём на использование инструмента PHP CS Fixer, рассмотрим полезные для нас правила и интегрируем с PHPUnit и PhpStorm.

После формы регистрации осталось добавить вход в кабинет и восстановление пароля.

Для этого перед программированием нам нужно определиться, как мы будем осуществлять аутентификацию в приложении из JS-фронтенда и API.

Как раз сегодня рассмотрим практики аутентификации по токенам при работе с API и сравним классические подходы с использованием токенов в формате JWT.

И смоделируем по шагам процесс получения и обновления токенов по универсальной спецификации OAuth2, чтобы с нашим API могли работать сторонние клиенты.

Мы с вами активно подключали сторонние компоненты, но в их исходники не заглядывали и код не анализировали. Пора это исправить :)

Для этого открываем обещанную ранее новую рубрику практического рефакторинга, где это будем делать.

Сегодня проведём разбор кода компонента OAuth 2.0 Server, который как раз будем использовать для аутентификации на бэкенде.

Сделаем форк репозитория и настроим локальный запуск тестов для проверки кода перед коммитом и отправкой Pull Request.

Займёмся упрощением кода сервера. Найдём и устраним избыточность интерфейса ответа. Удалим неиспользуемые аргументы. Увидим неудобство наличия сеттеров в сервисе и рассмотрим способы избавления от них. Избавимся от зависимости от конкретного класса путём добавления интерфейса для внедрения публичного ключа. И сделаем интерфейсы компактными.

Готов анонс новой рубрики скринкастов в блоге. Там подробнее, чем было здесь.

Подвезли новые релизы:

Сегодня обновим CS Fixer, переведём Doctrine ORM на использование PSR-6 для кэширования мета-информации, сделаем более безопасным Jenkinsfile и доустановим в образ Jenkins компилятор Rust для сборки зависимостей.

Приступаем к реализации полноценной системы аутентификации на бэкенде.

Сегодня исследуем работу готового компонента League OAuth2 Server и проинтегрируем его в наш PHP-проект. Напишем требуемые сущности и репозитории по интерфейсам компонента. Добавим сохранение авторизационного кода и токена обновления через Doctrine.

Помимо этого обновим Docker-образы и напишем свою функцию env для более удобной работы с переменными окружения.

Продолжаем интеграцию.

Когда у нас готовы сущности и репозитории создадим сам компонент OAuth-сервера. Для него сгенерируем файлы ключей и сделаем их деплой из Jenkins через Docker Secrets.

Сделаем страницу входа и контроллер для генерации и обновления токенов. Все контроллеры покроем функциональными тестами.

По аналогии с Command добавим Query-модель на DBAL для выполнения запросов на чтение данных из модуля.

И заодно рассмотрим, как можно избавиться от вызова синглтона SentrySDK в коде наших сервисов и экшенов.

После добавления полноценной генерации токенов пришла пора эти JWT-токены принимать и валидировать. И извлекать из них идентификатор пользователя для использования в контроллере.

Для этого создадим компонент сервера ресурсов. Добавим middleware для аутентификации и рассмотрим несколько вариантов его написания и использования.

Сегодня завершаем аутентификацию для бэкенда. Доделаем нюансы, не реализованные ранее.

Сначала добавим роль в JWT. Потом напишем генератор токенов для E2E тестов. И сделаем форсированное разлогинивание пользователя и автоочистку устаревших кодов из БД по Cron в Docker Swarm.