Карта директории server/ и её содержимого.

Дорожная карта проекта и дерево

Директория server/ содержит бэкенд на Go и встроенный медиасервер LiveKit. Директория apps/ содержит клиентские приложения.

bedrud/
├── apps/                # Клиентские приложения
│   ├── web/             # React-фронтенд (TanStack Start)
│   ├── android/         # Нативное Android-приложение
│   └── ios/             # Нативное iOS-приложение
├── server/              # Бэкенд на Go («Аплаенс»)
│   ├── cmd/             # Точки входа CLI (run, install)
│   ├── internal/        # Приватный код приложения
│   │   ├── auth/        # JWT, Passkeys, логика OAuth
│   │   ├── handlers/    # HTTP-контроллеры
│   │   ├── models/      # Схемы базы данных
│   │   ├── repository/  # Слой доступа к данным GORM
│   │   └── livekit/     # Управление медиасервером
│   ├── frontend/        # (Сгенерировано) Скомпилированные веб-ассеты
│   ├── config.yaml      # Шаблон конфигурации
│   └── Makefile         # Автоматизация сборки и развёртывания
└── docs/                # Системная документация (MkDocs)

Карта директорий

/cmd/bedrud

• main.go: Точка входа приложения. Обрабатывает CLI-команды, такие как run, install и livekit.

/config

• config.go: Определяет структуру Config и загружает настройки из config.yaml или переменных окружения.
• livekit.yaml: Конфигурация по умолчанию для встроенного сервера LiveKit.

/internal

• /auth: содержит логику генерации JWT, провайдеров OAuth и регистрации/входа через Passkey (WebAuthn).
• /database: управляет подключением к SQLite или PostgreSQL и запускает миграции.
• /handlers: HTTP-обработчики Fiber. Здесь находится логика для каждой конечной точки API (например, auth_handler.go, room_handler.go).
• /models: Модели базы данных GORM. Эти файлы определяют таблицы в вашей базе данных.
• /repository: «Слой доступа к данным». Обработчики вызывают репозитории вместо прямого написания запросов к БД, что сохраняет логику обработчиков чистой.
• /livekit: Интеграция с LiveKit Go SDK. Управляет созданием комнат и генерирует «токены присоединения» для участников.
• /middleware: Пользовательские middleware Fiber для проверки аутентификации, логирования и CORS.
• /server: Код-«клей», который объединяет всё воедино. Инициализирует базу данных, репозитории и запускает сервер Fiber.
• /install: Логика для команды bedrud install, которая автоматизирует настройку systemd и TLS на Linux.
• /scheduler: Фоновые задачи (если есть).
• /utils: Небольшие вспомогательные функции (например, хеширование паролей, случайные строки).

/migrations

• содержит SQL- или Go-файлы для обновления схемы базы данных.

/docs (внутри server)

• содержит файлы документации Swagger/OpenAPI (генерируются с помощью swag).

Техническое погружение

1. Встраивание бинарников («Трюк»)

Bedrud использует директиву //go:embed для упаковки файлов в скомпилированный бинарный файл.

• Фронтенд: Папка React dist/client/ (плюс пре-рендеренный index.html) встроена в server/ui.go. Статические файлы отдаются напрямую из памяти с использованием middleware filesystem от Fiber.
• Сервер LiveKit: Предварительно скомпилированный исполняемый файл livekit-server встроен в internal/livekit/bin/. Во время выполнения Bedrud извлекает его в /tmp/bedrud-livekit-server и запускает как фоновый процесс (internal/livekit/server.go).

2. Обратный прокси LiveKit

Чтобы избежать открытия нескольких портов (сигнализация, API и т. д.), Bedrud направляет весь трафик сигнализации LiveKit через свой основной HTTP(S)-порт.

• Любой запрос, начинающийся с /livekit, перехватывается в internal/server/server.go.
• Обратный прокси (с использованием httputil.NewSingleHostReverseProxy) перенаправляет эти запросы к внутреннему экземпляру LiveKit (обычно работающему на 127.0.0.1:7880).
• Прокси удаляет префикс /livekit перед пересылкой, позволяя LiveKit функционировать так, как будто он является корневым приложением.

3. Контекст middleware и Locals

Бэкенд использует .Locals от Fiber для передачи данных между middleware и обработчиками.

• Auth Middleware (internal/middleware/auth.go): Проверяет JWT и сохраняет объект Claims в c.Locals("user").
• Обработчики: Могут получить доступ к ID и правам текущего пользователя с помощью:

  claims := c.Locals("user").(*auth.Claims)
  userID := claims.UserID

4. Переопределение конфигурации

Хотя Bedrud использует файл config.yaml, почти каждую настройку можно переопределить с помощью переменных окружения. Это необходимо для сред Docker и CI/CD.

Стандарты кодирования и паттерны

Бэкенд следует этим паттернам:

1. Паттерн Repository

Обработчики не должны обращаться к базе данных напрямую. Используйте Repository. Это делает код легче для тестирования и позволяет изменять логику базы данных без изменения API-обработчиков.

2. Стандартизированная обработка ошибок

API-обработчики должны возвращать понятные сообщения об ошибках.

• Используйте c.Status(fiber.StatusBadRequest).JSON(...) для ошибок валидации.
• Используйте c.Status(fiber.StatusUnauthorized).JSON(...) для ошибок аутентификации.
• Используйте c.Status(fiber.StatusInternalServerError).JSON(...) для ошибок базы данных или сервера.

3. Структурированное логирование

Бэкенд использует Zerolog для логирования.

• log.Info(): Для важных событий (например, запуск сервера).
• log.Error(): Для сбоев.
• log.Debug(): Для подробной информации при разработке.

Избегайте использования fmt.Println для логирования в основной логике.

4. Соглашения об именовании

• Файлы: snake_case (например, user_handler.go).
• Структуры/Функции: PascalCase (например, GetUserByEmail).
• Переменные: camelCase (например, hashedPassword).