333 lines
17 KiB
Markdown
333 lines
17 KiB
Markdown
# Архитектурный обзор Plane CE под NodeDC
|
||
|
||
## Короткий вывод
|
||
|
||
Как база под локальный PoC и дальнейший форк Plane подходит.
|
||
|
||
Причины:
|
||
- monorepo прозрачный, фронт и бэк лежат рядом
|
||
- backend на Django с довольно прямой моделью данных
|
||
- frontend разбит на приложения и пакеты без сильной магии
|
||
- роли, проекты, workspace и work items вынесены в явные модели и API
|
||
- self-host runtime отделен от исходников, поэтому можно независимо разворачивать стенд и вести форк
|
||
|
||
Слабые места:
|
||
- есть шероховатости в self-host setup и в некоторых runtime-флоу релиза `v1.3.0`
|
||
- часть UI-строк все еще размазана по компонентам, не везде i18n идеально дисциплинирован
|
||
- attachment flow в текущем релизе выглядит хрупко
|
||
|
||
Что проверено уже на живом локальном инстансе:
|
||
- login/onboarding экран
|
||
- домашний экран workspace
|
||
- project issues/work items
|
||
- project views
|
||
- project settings
|
||
- profile settings
|
||
|
||
Фактический остаток после русификации на этих экранах небольшой:
|
||
- timezone label `Moscow Time`
|
||
- отдельные технические loader/accessibility строки вне основного happy-path
|
||
- часть secondary/admin экранов не аудировалась так же глубоко, как основной `apps/web`
|
||
|
||
## Как устроен frontend
|
||
|
||
Основное web-приложение:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/web`
|
||
|
||
Соседние приложения:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/admin`
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/space`
|
||
|
||
Технологически:
|
||
- React
|
||
- React Router
|
||
- TypeScript
|
||
- MobX stores
|
||
- Vite/react-router build
|
||
- общие UI/утилиты вынесены в workspace packages
|
||
|
||
Полезные пакеты:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/i18n`
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/services`
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/ui`
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/types`
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/shared-state`
|
||
|
||
Практически это удобно для форка:
|
||
- можно менять только `apps/web`, не трогая backend
|
||
- можно переопределять поведение через store/services слой
|
||
- локализация и общие UI-слои вынесены отдельно, это удобно для русификации и брендирования под NodeDC
|
||
|
||
## Как устроен backend
|
||
|
||
Основной backend:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api`
|
||
|
||
Технологически:
|
||
- Django
|
||
- Django REST style API
|
||
- Postgres
|
||
- Redis
|
||
- RabbitMQ
|
||
- MinIO/S3-совместимое хранилище
|
||
|
||
Модельный слой читаемый, без сложной скрытой генерации.
|
||
|
||
Ключевые модели:
|
||
- users: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/user.py`
|
||
- workspace: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/workspace.py`
|
||
- projects: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/project.py`
|
||
- issues/work items: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/issue.py`
|
||
- views: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/view.py`
|
||
- instance admin: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/license/models/instance.py`
|
||
|
||
## Где живет auth / users / roles / projects / work items
|
||
|
||
### Auth
|
||
|
||
Auth-слой:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/authentication`
|
||
|
||
Что видно на практике:
|
||
- есть email/password вход
|
||
- есть magic-code и OAuth-провайдеры
|
||
- session auth используется в license/admin API
|
||
- для локального PoC email/password сценарий нормальный и достаточно простой
|
||
|
||
Для NodeDC это плюс:
|
||
- можно оставить Plane как внутренний task-сервис
|
||
- внешнюю SSO/SSO-агрегацию лучше строить аккуратно через отдельный auth gateway или через ограниченный backend patch, а не переписывать весь auth слой сразу
|
||
|
||
### Users
|
||
|
||
Основная пользовательская модель:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/user.py`
|
||
|
||
Пользовательские настройки и профили привязаны к workspace/user preference модели, а не размазаны хаотично.
|
||
|
||
### Roles
|
||
|
||
Роли workspace/project заданы явно числовыми choice-полями.
|
||
|
||
Файлы:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/workspace.py`
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/project.py`
|
||
|
||
Базовая ролевая модель:
|
||
- `Admin`
|
||
- `Member`
|
||
- `Guest`
|
||
|
||
Это достаточно для PoC, но для NodeDC, если нужны тонкие корпоративные ACL, вероятнее всего придется строить внешний mapping или дополнительный policy layer.
|
||
|
||
### Projects
|
||
|
||
Файл:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/project.py`
|
||
|
||
Проект содержит нужный минимум:
|
||
- имя
|
||
- identifier
|
||
- network/доступность
|
||
- участники
|
||
- инвайты
|
||
- архивирование
|
||
|
||
### Work items / issues
|
||
|
||
Файл:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/issue.py`
|
||
|
||
Что важно practically:
|
||
- issue-модель богатая
|
||
- есть assignees
|
||
- comments
|
||
- attachments
|
||
- labels
|
||
- relations
|
||
- subscribers
|
||
- activity/history
|
||
- versions
|
||
|
||
Под встроенный task-management контур это хорошая база: предметная модель уже богаче, чем нужен минимальный NodeDC PoC.
|
||
|
||
## Что выглядит хорошими точками кастомизации
|
||
|
||
### 1. Frontend fork
|
||
|
||
Самая безопасная и быстрая зона кастомизации.
|
||
|
||
Что удобно менять:
|
||
- локализацию
|
||
- названия сущностей в UI
|
||
- onboarding
|
||
- проектные экраны
|
||
- навигацию
|
||
- виджеты карточек и work item detail
|
||
- интеграционные кнопки и ссылки в NodeDC
|
||
|
||
Причина:
|
||
- это в основном `apps/web`
|
||
- изменения изолируются без тяжелого вмешательства в доменную модель
|
||
- уже подтверждено практикой на этом стенде: русификация, переименование UI-лейблов и правка hardcoded строк делаются без вмешательства в backend
|
||
|
||
### 2. Слой сервисов и stores
|
||
|
||
Хорошее место для мягкой интеграции с NodeDC.
|
||
|
||
Файлы/пакеты:
|
||
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/services`
|
||
- store-слой внутри `apps/web/core/store` и `hooks/store`
|
||
|
||
Подходит для:
|
||
- прокидывания дополнительных данных из NodeDC
|
||
- feature-flags
|
||
- брендированных сценариев
|
||
- дополнительных UI-проверок
|
||
- синхронизации preferred language / workspace defaults / видимости пунктов меню
|
||
|
||
### 3. Bootstrap / seed / миграции рядом с runtime
|
||
|
||
Для PoC и внутренних стендов это удобно держать отдельно от core-кода Plane.
|
||
|
||
Что уже сработало:
|
||
- отдельный bootstrap-скрипт на Django shell
|
||
- demo-данные живут рядом с self-host runtime, а не смешаны с upstream
|
||
|
||
## Что лучше не трогать без необходимости
|
||
|
||
### 1. Базовый self-host stack целиком
|
||
|
||
Не стоит на старте переписывать:
|
||
- compose topology
|
||
- proxy слой
|
||
- очередь/redis/minio wiring
|
||
|
||
Причина:
|
||
- локальный runtime уже и так неидеален
|
||
- при ранней кастомизации инфраструктурного слоя слишком легко получить нестабильный стенд
|
||
|
||
### 2. Ядро auth-провайдеров
|
||
|
||
Не стоит сразу глубоко влезать в:
|
||
- `/apps/api/plane/authentication/provider`
|
||
- `/apps/api/plane/authentication/adapter`
|
||
|
||
Лучше сначала решить, нужен ли NodeDC-side SSO gateway, либо достаточно controlled login flow.
|
||
|
||
### 3. Низкоуровневый attachment/storage flow
|
||
|
||
По факту релиза `v1.3.0` это место уже выглядит хрупко.
|
||
|
||
Если кастомизировать загрузки и документы, лучше:
|
||
- сначала стабилизировать текущий runtime-флоу
|
||
- потом отдельно проектировать document-service интеграцию
|
||
|
||
Практический вывод по этому пункту:
|
||
- для NodeDC-сценария "запрос документов" Plane лучше использовать как UI и контур задач
|
||
- документный бинарный контент и его жизненный цикл разумнее держать в отдельном sidecar/document-service
|
||
|
||
## Что конфигурируется из коробки
|
||
|
||
Из практических вещей без тяжелого форка:
|
||
- self-host параметры через `plane.env`
|
||
- локальный URL/ports
|
||
- storage через MinIO/S3
|
||
- email/auth провайдеры
|
||
- язык пользователя
|
||
- workspace/project structure
|
||
- demo users/projects/issues
|
||
- i18n-переводы frontend UI
|
||
- локальные image tags для собственного форка frontend/admin/space
|
||
|
||
## Что, вероятно, стоит делать отдельным sidecar/service рядом с Plane
|
||
|
||
### 1. Корпоративная интеграция с NodeDC-админкой
|
||
|
||
Если NodeDC уже источник истины по оргструктуре, сотрудникам и ролям, лучше не вшивать это насмерть в core Plane.
|
||
|
||
Практичнее вынести рядом:
|
||
- sync-service пользователей
|
||
- sync-service оргструктуры / отделов / контуров
|
||
- mapping ролей NodeDC -> Plane workspace/project roles
|
||
|
||
### 2. Документный контур
|
||
|
||
Под сценарий “запросы документов” логично иметь sidecar:
|
||
- файловое/документное хранилище
|
||
- правила доступа к документам
|
||
- интеграцию с существующей NodeDC-документной подсистемой
|
||
|
||
Plane можно оставить как task/workflow UI, а не как единственный документный источник истины.
|
||
|
||
### 3. Внешние бизнес-правила
|
||
|
||
Если понадобятся:
|
||
- SLA
|
||
- маршруты согласования
|
||
- специфические статусы для бухгалтерии/менеджеров
|
||
- автоматическое создание задач из событий NodeDC
|
||
|
||
Это лучше сначала делать внешним orchestration/service слоем, а не перепахивать core issue lifecycle в Plane.
|
||
|
||
## Что можно синхронизировать с NodeDC-админкой
|
||
|
||
Наиболее реалистичные направления синхронизации:
|
||
- пользователи
|
||
- команды / отделы / контуры
|
||
- принадлежность к workspace/project
|
||
- справочник ролей и роль-mapping
|
||
- автосоздание проектов под контуры NodeDC
|
||
- начальные шаблоны проектов и saved views
|
||
- статусы и labels для типовых процессов вроде бухгалтерии и запросов документов
|
||
|
||
## Итог по пригодности под NodeDC
|
||
|
||
Для сценария "встроенный task-management контур внутри NodeDC" оценка положительная, если держать реалистичную границу кастомизации:
|
||
- Plane как готовое ядро задач, проектов, activity, comments, views и базовых ролей
|
||
- NodeDC как источник оргструктуры, корпоративных правил, документов и внешних интеграций
|
||
|
||
Нехороший путь:
|
||
- пытаться быстро превратить Plane в единственный источник истины по оргструктуре, документам и enterprise-ACL
|
||
|
||
Хороший путь:
|
||
- форк `apps/web` + ограниченные backend-патчи
|
||
- sidecar для sync и document workflows
|
||
- постепенное brand/UI-domain подстраивание под NodeDC
|
||
- автосоздание work items из событий NodeDC
|
||
- ссылки из NodeDC admin в конкретные work items Plane
|
||
|
||
## Практическая оценка пригодности под NodeDC
|
||
|
||
### Что уже хорошо
|
||
|
||
- есть рабочий self-hosted open-source контур
|
||
- модель projects/work items уже зрелая
|
||
- UI достаточно богат для быстрого PoC
|
||
- фронт реально поддается форку и русификации
|
||
- предметные сущности хорошо ложатся на сценарии “бухгалтерия / менеджеры / запросы документов”
|
||
|
||
### Что сыровато
|
||
|
||
- официальный self-host flow не полностью воспроизводим без ручных правок
|
||
- attachment/storage часть выглядит ненадежно
|
||
- не весь UI идеально дисциплинирован по i18n
|
||
- часть внутренних UX-решений все еще ориентирована на общий SaaS-сценарий Plane, а не на embedded B2B-контур
|
||
|
||
### Что опасно брать в глубокий форк
|
||
|
||
- глубокую переделку auth ядра на первом этапе
|
||
- радикальную переделку storage/attachments без отдельного тестового контура
|
||
- попытку сделать из Plane master-system для всего NodeDC вместо роли task/workflow сервиса
|
||
|
||
## Итог
|
||
|
||
Для сценария “встроенный task-management контур внутри NodeDC” Plane CE можно брать как базу под ручную докрутку.
|
||
|
||
Но разумная стратегия такая:
|
||
- Plane использовать как ядро task/work item UI и workflow-базы
|
||
- NodeDC оставить источником истины по оргструктуре и, возможно, идентификации
|
||
- сложные корпоративные правила и интеграции выносить в sidecar/sync services рядом
|
||
|
||
То есть: как стартовая база для PoC и дальнейшего прикладного форка подходит, как готовый безболезненный enterprise-foundation из коробки — нет.
|