Skip to main content

Архитектура Lowcode Platform

Общий обзор архитектуры платформы, связей между модулями и потоков данных.

🎯 Зачем эта страница​

Этот раздел даёт общее понимание:

  • из каких крупных компонентов состоит платформа;
  • как они связаны между собой;
  • какой путь проходит данные — от визуального редактора до исполнения готового приложения;
  • какие модули являются основными и как они взаимодействуют.

Это точка входа для понимания всей системы в целом.

1. Карта системы (высокоуровневый вид)

Платформа состоит из нескольких ключевых модулей:

apps/
  api/                ← Backend (NestJS + Fastify + Prisma)
  builder-web/        ← Визуальный редактор (React + Vite)
  docs/               ← Документация (Docusaurus)

packages/
  dsl/                ← Описание типов и структуры DSL
  dsl-compiler/       ← Компилятор DSL → AST → Bundle
  expression-parser/  ← Парсер для выражений внутри DSL (микро-DSL)
  shared-types/       ← Общие типы между API и редактором
  runtime-core/       ← Ядро runtime preview для builder-web
  ui-kit/             ← UI-компоненты редактора

Взаимодействие модулей:

[ builder-web ] → HTTP → [ api ] → PostgreSQL
       ↓                         ↑
       ↓                         │
   [ dsl-compiler ]  ↔  используется api для валидации/компиляции
       ↓
[ сгенерированный бандл ] → выполняется в runtime-host

2. Поток данных: от редактора к исполнению

Ниже приведён последовательный путь, который проходит проект пользователя.

Шаг 1: пользователь создает/редактирует проект в builder-web​

  • редактор собирает структуру интерфейса в виде DSL-дерева;
  • проект сохраняется в API как JSON (структура компонентов).
React state → DSL JSON → POST /projects → PostgreSQL

Шаг 2: пользователь нажимает «Скомпилировать»​

  • builder-web вызывает dsl-compiler (как библиотеку);
  • компилятор:
    • валидирует DSL;
    • строит AST;
    • генерирует JS-бандл;
    • возвращает клиенту.
DSL → AST → JS bundle

Шаг 3: builder-web отображает превью​

В редакторе подтягивается механизм выполнения бандла с помощью runtime-core:

  • бандл динамически подключается;
  • выполняется в sandbox-окружении React;
  • на экране отображается рендер готовой страницы.

Это позволяет в реальном времени видеть результат работы DSL.

Шаг 4: runtime-host выполняет приложение (WIP)​

Когда пользователь разворачивает проект:

  • бандл отправляется в runtime-host;
  • он выполняет его как клиентское приложение;
  • обеспечивает доступ к внешним действиям (HTTP, storage и т.п.).

3. Подсистемы архитектуры

3.1. builder-web (визуальный редактор)​

Роль:

  • предоставляет drag-n-drop интерфейс для построения страниц;
  • редактирует структуру компонентов;
  • сохраняет и загружает проекты через API;
  • генерирует DSL дерево;
  • показывает превью результата.

Ключевые элементы:

  • React компоненты
  • Vite dev-server
  • локальное состояние редактора
  • клиент для API

3.2. API (backend)​

Роль:

  • управление проектами и их версиями;
  • валидация DSL структур;
  • компиляция DSL через dsl-compiler;
  • сохранение и загрузка проектов из PostgreSQL;
  • предоставление REST API редактору.

Технологии:

  • NestJS + Fastify
  • Prisma + PostgreSQL
  • Docker для окружений

Основные эндпоинты:

/projects
/project-versions
/validate
/compile

3.3. DSL + DSL Compiler (packages/dsl + packages/dsl-compiler)​

Роль:

  • преобразовать дерево DSL в исполняемый AST;
  • выполнять валидацию корректности DSL;
  • генерировать готовый JS-бандл;
  • предоставлять инструменты для расширения языка компонентов.

Этапы трансляции:

DSL → нормализация → AST → генерация кода → бандл

3.4. Runtime-host (WIP)​

Роль:

  • выполнять сгенерированный JS бандл;
  • предоставлять окружение (контексты API, сторы, экшены);
  • обеспечивать безопасное выполнение.

Пока хост может быть простым, но архитектура допускает его расширение:

  • sandbox
  • системные действия (HTTP, навигация, состояния)
  • интеграции

4. Как модули связаны друг с другом

4.1. builder-web ↔ API​

builder-web использует API:

  • для загрузки проектов;
  • для сохранения проектов;

В будущем также возможно:

  • для компиляции;
  • для валидации.

Это главный канал связи.

4.2. API ↔ dsl-compiler​

API вызывает функции компилятора напрямую как библиотеку.

Это означает:

  • нет отдельного сервиса «компилятора»;
  • скорость значительно выше;
  • проще сопровождать код.

4.3. builder-web ↔ runtime-host​

На этапе разработки:

  • builder-web выполняет бандл сам.

На этапе продакшена:

  • runtime-host получает бандл и исполняет.

5. Диаграмма архитектуры (упрощённая)

graph TD
  A[builder-web
  (React + Vite)] -->|HTTP| B[API
  (NestJS + Fastify)]
  B --> C[(PostgreSQL)]
  B --> D[dsl-compiler]
  D --> E[Bundle JS]
  A --> E
  E --> F[runtime-host]

6. Что важно понимать разработчику

  1. Платформа делится на редактор, бэкенд, компилятор, рантайм.
  2. Основной «контракт» модулей — это DSL дерево.
  3. dsl-compiler — ключевой слой преобразования.
  4. Вся логика данных живёт в API.
  5. builder-web определяет UX и визуальные инструменты.
  6. runtime-host — конечная среда выполнения.

Следующие страницы раздела будут углубляться в каждый компонент:

  • архитектура API;
  • архитектура редактора builder-web;
  • цикл компиляции DSL;
  • структура рантайм-хоста.