Skip to content

Требования к системе

С точки зрения разработки.

Определения

Система - система учета Мойсклад.

Вендор - поставщик решений для Маркетплейса решений Мойсклад.

Графические интерфейсы:

Идентификационные данные:

Придумывает вендор:

  • vendor_name - имя вендора, указывается однажды при регистрации нового вендора.
  • app_name - это имя приложения, указывается единожды при создании приложения.

Генерирует система:

  • app_uuid, app_id - это уникальный идентификатор приложения в формате UUID.
  • app_uid - это уникальный идентификатор приложения в формате строки вида, составляется так app_name.vendor_name.
  • secretKey - секретный ключ, используется для получения контекста в интерфейсах приложения. Благодаря этому ключу система верифицирует запрос контекста.

Эндпоинты

  • /vendor_endpoint - точка для всех вендорских запросов: установка, удаление, покупка/продление подписки, смена тарифа и пр. Полное описание (Vendor API)[https://dev.moysklad.ru/doc/api/vendor/1.0/#vendor-api-1-0].
  • /<app_name> - главный графический интерфейс приложения
  • /<app_name>/* - еще страницы главного графического интерфейса приложения (сейчас это только /login в edocsuz-sync)
  • /<app_name>/gui/widget/* - страницы виджетов по типам документов (например /edocsuz-sync/gui/widget/demand), тут же эндпоинты с запуском логики виджета (например /edocsuz-sync/gui/widget/create_document).
  • /<app_name>/webhook-processor - эндпоинт, куда Мойсклад шлёт вебхуки. Наша система сохраняет запросы и ставит их в очередь.
  • /<app_name>/internal-webhook - эндпоинт, куда приходят вебхуки из внутренней очереди. Тут происходит работа, заложенная в логике приложения.

Сервисы GUI и BACKEND

Эндпоинты разделены на 2 группы:

  1. GUI - на основе библиотеки NiceGUI (только основные интерфейсы приложений)
  2. BACKEND - все остальные (эндпоинты для вебхуков, виджеты на основе библиотеки Jinja).

Империческим путем было выяснено, что при обработке BACKEND запросов сервисом, где запущен NiceGUI, запросы в какой-то момент перестают обрабатываться и сервис подвисает целиком. И все эндпоинты были разделены таким образом, так как чистый FastAPI (без NiceGUI) лучше справляется с масштабированием под нагрузкой.

Сервисы в docker compose называются соответствующим образом: gui и backend0.

Девелоперсие приложения

Сюда же относятся версионные — это те, что создаются при отправке новой версии приложения на модерацию. Например для приложения payments-linking версионное приложение будет иметь вид payments-linking-3-rvrux.

Для нашего ПО важно поддержать одновременно две версии приложения: основную и версионную. То есть оба приложения должны работать одинаково, на одних и тех же эндпоинтах.

Реализуется это за счет дублирования эндпоинтов. Одни эндпоинты постоянны и неизменны, составляются на основе константных app_name, а вторые используют те данные, что прописаны в apps.env и могут быть изменены в зависимости от цели.

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