Резюме

Пишу на PHP с 2009 года, коммерческая разработка с 2011 года, работаю удалённо с 2016 года.

Основная специализация – бэкенд, но примерно с 2018 г. активно занимаюсь и фронтендом.

Бэкенд

С 2016 года работаю исключительно с Laravel. Хорошо разбираюсь в устройстве фреймворка, пишу библиотеки, делаю SaaS и приватные/публичные API, пишу тесты (PHPUnit, Pest) и документацию.

Люблю решать архитектурные вопросы, не боюсь рефакторинга и дебага. Если в опенсорс библиотеке не хватает какой-то функциональности, с радостью делаю пулл-реквесты.

Разумеется, есть большой опыт работы с различными библиотеками – как Laravel-related (привет, spatie/), так и общие.

Другие фреймворки

В силу того, что подбираю вакансии, где требуется Laravel, с Symfony практически не работал, и скорее всего вакансии с Symfony рассматривать не буду.

Несмотря на то, что стараюсь писать код как можно framework-agnostic, и перейти на новый фреймворк, в целом, не должно быть болезненно, всё же большой опыт работы с Laravel позволяет вести разработку намного быстрее.

Фронтенд

Весь фронтенд делаю на VueJS. На новых проектах использую Composition API. Занимаюсь как клиентскими приложениями, так и админками. В течение 2022 года переносил большое бэкофис-приложение с Vue 2 на Vue 3, параллельно делая редизайн с Bootstrap-шаблона на компоненты Tailwind UI.

Верстаю с Tailwind CSS, считаю его удобным инструментом, несмотря на критику «inline-стилей» и раздутых HTML.

Другие фреймворки

Как-то давно делал пару проектов на Ionic Framework v3 (использовался Angular). Так же сталкивался с Nuxt 3.

Опыт работы с React и Next.JS минимальный. Понимаю важность фреймворка, но работать с ним после Vue некомфортно (хотя, как минимум одну фичу из React я бы хотел видеть в Vue – forwardRef).

Однако, если приспичит, могу заморочиться и сделать давно запрашиваемый PR в React/Vue библиотеку (дополненный мейнтейнером, но всё же). Или перенести Catalyst UI Kit с React на Vue (к сожалению, команда Tailwind Labs не разрешила опубликовать его).

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

Пишу как спецификации API (OpenAPI/Swagger), так и документацию в виде гайдов для разработчиков (в том числе внутреннюю).

Опыт работы

Несмотря на 10+ лет стажа, я не описываю более ранний опыт работы, т.к. сейчас он уже неактуален. Вместо этого рассказываю о последнем проекте и наиболее интересных задачах, которые приходилось решать.

Последний проект – Zenky – Headless eCommerce платформа (программа лояльности, конструкторы сайтов и моб. приложений, API-first подход, обмен данными, кастомизация через настройки).

Цель проекта – дать возможность бизнесу создать интернет-магазин, подключить сайт (опционально – мобильное приложение), всё настроить и начать принимать заказы.

Zenky используют крупнейшие ритейлеры и рестораны Республики Бурятия, такие как Абсолют, Титан (оба используют только моб. приложения, сайты свои), Sushi House, Яроллов и другие. Кроме Бурятии проект охватывает всю Россию – от Калининграда до Владивостока.

В среднем за год платформа обрабатывает около миллиона заказов на сумму более 1.5 млрд. рублей.

Ключевые точки

Проект разрабатывался в одиночку (кроме моб. приложений), поэтому весь описанный опыт – мой.

• Единый API для клиентов, версионирование, гибкая настройка разрешений токенов, вебхуки и вебсокеты.
• Специальный API для синхронизации каталога из внешних источников с сопоставлением ID.
• Вся кастомизация магазина выполняется через большое количество пользовательских настроек.
• Кэшбэк и оплата заказов бонусами. Гибкий редактор акций и подарков. Массовое применение скидок (в том числе по расписанию).
• Конструктор сайтов с возможностью подключить свой домен и выдать бесплатный SSL-сертификат.
• API настроек (полей формы), через которые можно управлять внешним видом моб. приложений из админки.
• API для разработки, подключения и настройки внешних интеграций (маркетплейс интеграций).
• Документация: OpenAPI-спецификация и гайды для разработчиков.

Ниже можно прочитать о каждом пункте более подробно.

API и версионирование

Все клиенты (сайты и моб. приложения) работают исключительно по единому API. Микросервисы и внутренние проекты так же используют этот API. Админка работает на той же кодовой базе, но использует другую мажорную версию API.

API версионирован – имеется стабильная документированная версия для клиентов (v2), недокументированная для админки (v3) и стабильный легковесный API для клиентов (Storefront v1). Вся основная и критичная логика переиспользуется во всех версиях API, что сильно помогает избежать дублирования кода и упрощает поддержку.

Сторонние разработчики могут создавать персональные токены с гибкой настройкой разрешений – все скоупы сгруппированы по тематике (например, работа с каталогом и работа с заказами - разные группы) и дополнительно разделены на read/write/destroy права.

Работа с событиями построена на вебхуках (для server-server интеграций) и вебсокетах (для клиентских приложений).

Магазины

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

Импорт каталога

Для eCommerce-платформы главная функциональность – каталог товаров и оформление заказов. Каталог (товары, варианты товаров, категории, коллекции, характеристики и т.д.) может быть наполнен как вручную (через админку), так и из сторонних источников через специальный API обмена данными.

Для того, чтобы не перемешивать между собой разные источники данных (например, 1С, Frontpad или Iiko), был разработан API для пакетного импорта данных. Каждая интеграция реализована через отдельное приложение, которое готовит данные для импорта и отправляет их в Zenky (а так же принимает вебхуки заказов из Zenky и отправляет их во внешнюю систему).

API сопоставляет внешние и внутренние ID, благодаря чему внешним системам не нужно проверять, был ли ресурс уже создан или нет. Такое сопоставление так же позволяет создавать зависимые ресурсы в любом порядке – к примеру, можно сначала импортировать товары (указав внешние идентификаторы категорий), и только потом импортировать категории. Если внешние ID категорий совпадают, категории будут привязаны к ранее созданным товарам автоматически.

Система настроек магазина

Так как все магазины работают на одной кодовой базе, крайне важно было иметь систему настроек для кастомизации логики работы. У магазинов есть возможность настроить работу каталога, заказов, каналов продаж (сайты и приложения), программы лояльности и других систем – всего более 200 кастомизируемых параметров.

За счёт этого в проекте нет захардкоденных значений (например, идентификаторов), а магазины в любое время могут изменить поведение системы. Настройки появляются тогда, когда возникает вопрос «А нужна ли эта фича всем магазинам?» или же когда нужно поменять существующую логику работы в одном магазине так, чтобы не затронуть других клиентов.

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

Программа лояльности

Делая заказы, покупатели могут получать кэшбэк, которым затем могут оплачивать новые заказы. Процент кэшбэка и оплаты заказов устанавливают сами магазины – в том числе через бонусные уровни (чем выше уровень, тем выше процент кэшбэка/оплаты; уровни так же настраиваются магазином).

Так же в программе лояльности есть редактор акций, позволяющий задавать гибкие правила выполнения акций и выдачу подарков. Например, магазин может создать акцию, при которой покупатель должен купить 2 товара из определённой категории на требуемую сумму, а в качестве подарка получит бесплатный товар на выбор, скидку или бонусы (или всё вместе).

Для массового применения скидок есть возможность создать расписание скидок – магазин указывает дату начала и окончания, расписание (например, скидки могут действовать только с 12:00 до 14:00 в будние дни), а так же сумму или процент скидки и список нужных товаров. Система автоматически применяет скидку к товарам в указанный период и отключает скидки по истечению времени работы.

Конструктор/хостинг сайтов

После создания сайта магазин может настроить его внешний вид через конструктор. Он поддерживает переопределение основных цветов, настройки конкретных блоков, редактирование текста, подключение собственных CSS/JS и создание дополнительных страниц.

Все настройки конструктора задаются на уровне шаблонов, для этого был разработан формат настроек, которые регистрируются в API конструктора и подгружаются в редакторе. Конечные сайты получают значения настроек через инъекцию JSON напрямую в HTML страницы.

Ко всем сайтам можно подключить свой домен (по умолчанию сайты работают на домене третьего уровня) и настроить SSL-сертификат (Let`s Encrypt).

Конструктор приложений

Помимо сайтов магазины могут выпускать мобильные приложения для iOS и Android (через менеджеров). Для кастомизации приложений так же был разработан конструктор, который позволяет настроить иконки, цвета, тексты, меню и т.д.

Основа конструктора приложений – усовершенствованный API кастомных настроек, который используется в конструкторе сайтов. Он получил больше встроенных полей и больше опций для конкретных типов настроек.

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

Внешние интеграции

Эта же система кастомных настроек используется для создания интеграций с внешними сервисами (те самые 1C, Frontpad и Iiko, описанные выше). Сторонние разработчики могут создать интеграцию, зарегистрировать настройки и дать возможность клиентам Zenky устанавливать интеграции в свои магазины.

Интеграции имеют стадии подключения, установки (если требуется) и отключения. На всех стадиях разработчик может указывать поля настроек – например, для ввода API-токена или выбора организации.

Если для работы интеграции требуется токен от API Zenky, разработчик указывает нужные разрешения, а владелец магазина – одобряет их, после чего интеграция получает токен и может работать с API. Если разрешения изменились, владелец магазина должен будет одобрить их заново, иначе интеграция не получит новый токен.

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

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

Весь API имеет документацию в двух видах – API Reference по спецификации OpenAPI (бывший Swagger) и документация разработчика с примерами использования и подробным объяснением работы API.

Для OpenAPI-спецификации было разработано небольшое CLI-приложение, которое переводит кастомизированный YML-файл в валидную спецификацию. Сайт спецификации генерируется с помощью ReDoc