SILVER
/
NODEDC_TASKMANAGER
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NODEDC_TASKMANAGER/ARCH_REVIEW_NODEDC_RU.md

17 KiB
Raw Blame History

Архитектурный обзор 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 из коробки — нет.