ShariX Open Docs

Проект Sharix Open - идет в основу каждого нового разворачиваемого сервиса, который предполагается, что будет функционировать на основе платформы ShariX.

Тестирование последней версии ShariX Open происходит на виртуальной машине Test (dev-сервер) - https://testopen.sharix.org. Доступ к ней и к процессу тестирования могут получить разработчики команды ShariX Open и практиканты компании ООО «ШЭРИКС».

Разворачивание сервиса выглядит как клонирование репозитория в отдельную виртуальную машину (или набор виртуальных машин - решение о конкретной инфраструктуре принимают создатели) сервиса.

Каждый сервис должен разворачиваться по аналогии с Open методом первоначального клонирования open-webapp-base (AGPL), но не-AGPL-репозитории берутся из группы репозиториев сервиса (в рамках компании ООО «ШЭРИКС» - на собственном git в организации по названию сервиса).

В конфигурации внутри webapp-base прописываются пути для клонирования для конкретного сервиса, конфигурация создается на основе черновика, в котором прописаны пути для клонирования Open. Первоначально группа репозиториев по названию сервиса создается методом полного клонирования Open, а затем форком (замена имен и файлов в некоторых репозиториях). Далее обновление виртуальной машины происходит методом обновления группы репозиториев сервиса.

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

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

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

В частности, *-backend (AGPL) содержит модели и шаблоны обработчиков событий. Его видоизменять не нужно для функционирования нового сервиса.

Так как у каждого сервиса свои обработчики - они копируются из open-backend в репозиторий *-webservice-running с соответствующим переименованием. Внутри разворачиваемого проекта оно должно в итоге оказаться там же. Вопрос лишь в том, в репозитории с каким смыслом и лицензией он выкладывается в гит.

Таким образом, в каждом сервисе, создаваемом на основе Open - остаются обработчики от Open - как пример, и есть свои обработчики сервиса, в webservice-running. Также в репозитория webservice-running (GPL) добавляется вся специфика сервиса, какая только может понадобиться ему - backend. Содержимое иных репозиториев с точки зрения разворачивания сервиса и ведения разработки:

• В webadmin (GPL) - внешний вид админ-панели.
• Landing (GPL) - посадочная страница сервиса
• Design-template (GPL) - шаблон дизайна
• User-model (AGPL) - базовая модель пользователя
• Tickets (AGPL) - интерфейс отображения заявок и управления ими
• Payments (GPL) - модуль для базовой обработки платежей с помощью платформы ShariX

Ниже представлены основные тезисы в виде заметок на ходу.

• Репозиторий sharix-open-backend
• Папка metaservicesynced
• Берем urls.py и по аналогии описываете или группу ссылок (router) - или отдельную (urlpatterns)
• Далее надо пойти в apiviews и создать файл по аналогии с имеющимися с MVS, добавленной действием ранее в urls.py
• queryset - таблица, к которой обращаемся
• SerializerClass - далее надо будет создать такой файл в папке serializer
• permission_classes - для ограничения доступа
• потом в init.py класс импортировать (по сути указать связь ссылки и MVS), чтобы он заработал (в той же папке, где view создавали)
• далее идем в папку serializer и создаем там файл с классом, о котором говорилось выше
• и в init.py по аналогии для serializer тоже
• Обработка происходит в serializer
• После дописывания перезапустить сервер

Чтобы искать по полям, отличным от id - надо в view вставить:

lookup_field = «status» (вместо status - nо поле, по которому получать ответ)