base
This commit is contained in:
DCCONSTRUCTIONS
@@ -0,0 +1,332 @@
|
||||
# Архитектурный обзор 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 из коробки — нет.
|
||||
Reference in New Issue
Block a user