Как от Open перейти к собственному сервису?

Проект 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. Содержимое иных репозиториев с точки зрения разворачивания сервиса и ведения разработки:

ЧЕРНОВИК/старое Как написать новый вызов API для ShariX Open

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

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

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