[VESP] Заготовка для SPA сервисов с REST API

Привет, друзья!

Наверное, вы уже обратили внимание, что я не был особо активен в этом году в сообществе. Причина в том, что я набрал кучу работы, с которой смог разобраться вот только что. И работа эта с MODX была никак не связана — я писал собственное решение для сложных проектов, с нуля.



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

Во-первых, это не готовое решение, не CMS. Это заготовка для старта нового проекта, в которой уже сделана основная структура.

Во-вторых, она не следует всем модерновым техникам, например используется устаревший паттерн Service Locator. А запросы обрабатывают процессоры через единую точку входа, а не контроллеры с прописанными маршрутами.

Это всё потому, что я из мира MODX, и лично мне так привычно и удобно. Соответственно, когда я придумывал систему «для себя», я сделал так, чтобы было удобно именно мне. Так что, когда вас посетит ощущение «где-то я уже это видел» — так и есть, вы видели это в MODX.

Ну а теперь, если вы готовы, знакомьтесь с VESP:
— Vue.js ( + Nuxt.js)
— Eloquent ORM
— Slim3 micro-framework
— Phinx migrations

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

Быстрый старт

1. Клонируем репозиторий VESP на хостинг
2. Переходим в core и переименовываем .env.dist в .env
3. Меняем настройки в .env — нужно указать адрес для запросов в API, подключение к БД и всё такое
4. Запускаем composer install
5. Запускаем ./vendor/bin/phinx migrate — это создаст стандартные таблицы для юзеров
6. Запускаем ./vendor/bin/phinx seed:run — это создаст стандартные записи в таблицах

Серверная часть готова, дальше фронтенд. Его можно разрабатывать на хостинге, или локально. Лично я предпочитаю локально, поэтому:
1. Клонируем репозиторий себе на комп
2. Скачиваем .env с хостинга, или меняем локально — нам нужна настройка SITE_URL
3. Идём в директорию frontend и делаем там npm install && npm run dev

Если всё сделали верно, то запустится локальный сервер разработки по адресу localhost:5112. Открываем его в браузере и проверяем, чтобы запросы уходили на хостинг — там их должно ловить ядро и отвечать. По умолчанию в .env включен параметр CORS, поэтому всё работает с удалёнными запросами.

Как работает ядро

Все запросы должны прилетать на www/index.php, там прописан единственный маршрут для API.

$app->any('/api[/{name:.+}]', function ($request, $response, $args) use ($container) {
  $container->request = $request;
  $container->response = $response;

  return (new Api($container))->process($request, $response, $args);
});

Дальше срабатывает контроллер core/src/Controllers/Api.php. Его задача — найти запрошенный процессор, загрузить юзера (если он авторизован) и запустить процессор.

Все процессоры находятся в core/src/Processors. В корне директории лежат абстрактные классы для наследования, а во вложенных директориях уже рабочие.

Например, пришёл запрос на api/web/test — значит процессор должен лежать в core/src/Processors/Web/Test.php.

Каждый процессор может отвечать на какой-нибудь тип запроса, то есть иметь методы post, put, patch, delete. Каким методом запрос пришёл — такой метод внутри процессора и дёргается. Если процессор должен только что-то отдавать, и метода put там просто нет, то на запрос put будет ошибка.

Проверка прав реализована свойством scope. Если там что-то есть, то этот scope будет проверяться у группы авторизованного пользователя. Причём, у группы может быть как полный scope на действие, например users, так и только на определённые методы — users/get.

Для работы используются модели Eloquent, пишутся они вручную. Таблицы создаются через миграции — смотрите как сделаны таблицы и модели user и user_roles, это понятный пример. Ну и читайте документацию Eloquent, она очень подробная.

Ну и основной класс со всеми сервисами — Container. Он прокидывается в контроллеры и процессоры, позволяя использовать свои сервисы или свойства, например обращаться к $this->container->user. Да-да, совсем как $this->modx->user.

Как работает фронтенд

Это я уже рассказывал в заметке про Nuxt.js.

Но в VESP сразу из коробки подключены нужные модули и настроена авторизация в админку. Так же есть и страницы для работы с пользователями и группами, включая выдачу им нужных scope. Для оформления используется замечательный BootstrapVue с кучей готовых компонентов.

Обратите внимание и на мои компоненты (они лежат в директории components) для простой реализации грида с модальными окнами создания, редактирования и удаления. Всё как в нежно любимом нами ExtJS менеджере MODX.



Для авторизации используется @nuxtjs/auth, работает она через токены. Причём, токены пишутся в БД на сервере, чтобы можно было ограничить количество одновременных подключений и отозвать их у отключенного пользователя. Это очень частый вопрос при работе с токенами, так что я включил его в базовый функционал — смотрите метод Container::makeToken().

После окончания локальной разработки собираем проект через npm run build и выгружаем на сервер. Я всё храню прямо в директории frontend в корне, а запросы разруливает Nginx.

if ($request_uri ~ ".*/$") {
    rewrite              ^/(.*)/$    /$1 permanent;
}

location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /index.php?q=$1;
}

location / {
    root    /home/vesp/frontend/dist/;
    try_files    $uri /200.html;
}

location ~* ^.+\.(jpg|jpeg|gif|css|png|js|ico|bmp|ttf|woff|woff2|svg)$ {
    root                /home/vesp/frontend/dist/;
    access_log          off;
    log_not_found       off;
    expires             10d;
    break;
}

Собственно, и собираю я фронтенд после разработки тоже на сервере, так быстрее.

Заключение

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

Понятное дело, что это не для сайтов-визиток и магазинов-однодневок. Это для больших сервисов, типа krafti.ru — где всё сделано с нуля под заказчика, работает очень быстро и выдерживает хорошие нагрузки. Например о том, что на сайте была распродажа и за день прошло более 2000 покупок, я узнал только на следующий день от радостных клиентов — а не как обычно, когда сервер начал тупить.

Это потому, что сервер больше не занимается рендерингом, а обрабатывает только API запросы. Всё оформление рисует браузер посетителя, избавляя сервис от лишней нагрузки.

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

Я понимаю, что заметка довольна сумбурная, но как-то более подробно расписать результат почти года работы у меня нет сил. Это-то выложить собирался почти месяц.
Поэтому пишите вопросы по узким местам, буду отвечать и дорабатывать текст по мере необходимости.

Исходный код — github.com/bezumkin/VESP