BFF Java to Java Script

Я занимаюсь фронтенд‑разработкой и имею опыт миграции серверных решений между технологическими стеками. В этой статье поделюсь опытом переноса BFF‑сервиса с платформы Java Servlet на современный фреймворк NestJS (на базе Node.js и TypeScript), а также сопутствующей настройкой инфраструктуры и тестового покрытия.

Исходный проект

Исходный проект представляет собой веб‑приложение со следующими характеристиками:

  • Фронтенд: реализован в виде SPA на базе Vue.js.
  • Бэкенд‑для‑фронтенда (BFF): выполнен на Java Servlet.
  • Сборка проекта: осуществляется с помощью Maven.
  • Развёртывание: выполняется на сервере приложений Apache Tomcat.
  • Процесс развёртывания: осуществлялся вручную путём копирования собранного артефакта (WAR‑файла) в соответствующую директорию на сервере.
  • Тестирование: отсутствовало автоматизированное тестовое покрытие — все проверки выполнялись вручную либо через прямые запросы к API.

Такая архитектура требует аккуратной миграции серверной части без нарушения работы клиентского приложения. Ручной способ развёртывания и отсутствие тестов подчёркивают необходимость:

  • автоматизации процессов сборки и развёртывания в новой инфраструктуре;
  • внедрения комплексного тестового покрытия (юнит‑, интеграционные и E2E‑тесты) на этапе перехода на современный стек.

Актуальность задачи

Переход с Java Servlet на NestJS (при сохранении фронтенда на Vue.js, который будет размещаться через Nginx) обусловлен следующими преимуществами:

  • Унификация стека: использование единого языка (TypeScript) на фронтенде и бэкенде упрощает командную разработку.
  • Повышенная продуктивность: декларативный стиль NestJS, встроенная поддержка DI и модульности сокращают время на написание и поддержку кода.
  • Богатая экосистема: npm‑пакеты и готовые решения для типичных задач (валидация, логирование, кеширование).
  • Удобство тестирования: встроенная интеграция с Jest и возможностями мокирования.
  • Гибкость развёртывания: лёгкость контейнеризации (Docker) и масштабирования в облачных средах. NestJS‑приложение запускается в отдельном Docker‑контейнере, что обеспечивает изолированность бизнес‑логики, удобство обновления и горизонтального масштабирования бэкенда, статический Vue.js‑фронтенд размещается в отдельном контейнере с Nginx, что гарантирует высокую производительность доставки статических ресурсов и гибкость настройки HTTP‑параметров.

Совместимость с существующей инфраструктурой

При этом важно сохранить совместимость с существующей инфраструктурой:

  • аутентификация через NTLM (Windows Integrated Authentication);
  • проксирование через Nginx с сохранением семантики запросов и заголовков;
  • внедрение полного тестового покрытия, включая E2E‑тесты с имитацией NTLM‑аутентификации (в исходном проекте тесты отсутствовали).

Ключевые задачи:

  • обеспечить бесшовный переход без потери функциональности для клиентов;
  • сохранить совместимость с корпоративными политиками безопасности (NTLM);
  • внедрить надёжное тестовое окружение для верификации работы сервиса после миграции;
  • автоматизировать процессы сборки и развёртывания (в противовес ручному копированию файлов);
  • предоставить практические рекомендации по устранению типичных проблем.

Структура гайда

Материал разбит на логические блоки:

  1. Перенос BFF на NestJS

    • Установка зависимостей express-ntlm:
      $ npm install express-ntlm
    • NTLM middleware:
      import { Injectable, NestMiddleware } from '@nestjs/common';
import { Request, Response, NextFunction } from 'express';
import ntlm from 'express-ntlm';

@Injectable()
export class NTLMMiddleware implements NestMiddleware {
    use(req: Request, res: Response, next: NextFunction) {
    return ntlm({
      domain: process.env.DOMAIN,
      domaincontroller: process.env.DOMAIN_CONTROLLER,
    })(req, res, next);
    }
  }

  export class AppModule {
    configure(consumer: MiddlewareConsumer) {
    consumer.apply(NTLMMiddleware).forRoutes('*');
  }
}

  2. Настройка Nginx и NTLM

    Конфигурация прокси и аутентификации.

    • Nginx NTLM-модуль — это дополнительный модуль для веб-сервера Nginx, который позволяет реализовать аутентификацию по протоколу NTLM.
    • Проверка версии Nginx:
      $ nginx -v # nginx version: nginx/1.26.3
    • Сборка и установка модуля (сокращённо).
    • Настройка конфигурации:
      {
  upstream http_backend {
    server 127.0.0.1:8080;
    ntlm;
  }

  server {
    ...
    location /http/ {
    proxy_pass http://http_backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
  }
}

  3. Добавление тестов Cypress

    Интеграция E2E‑тестов с поддержкой NTLM.

    • Установка Cypress и плагина:
      $ npm install cypress --save-dev
$ npm install cypress-ntlm-auth --save-dev
    • Настройка аутентификации NTLM в тестах.

  4. Добавление Redis для кэширования и управления сессиями

    Внедрение Redis при миграции BFF‑сервиса на NestJS позволит:

    • снизить нагрузку на основную базу данных за счёт кэширования часто запрашиваемых данных;
    • обеспечить масштабируемость при горизонтальном развёртывании нескольких инстансов NestJS‑приложения (общее хранилище сессий);
    • реализовать фоновые задачи и очереди сообщений (при дальнейшем развитии системы);
    • ускорить отклик API за счёт хранения промежуточных результатов вычислений.

    Установка зависимостей:

    $ npm install @nestjs/redis cache-manager redis
$ npm install --save-dev @types/redis</pre>

  5. Контейнеризация с Docker и Docker Compose

    Создание образов и оркестрация сервисов:

    • подготовка Dockerfile для NestJS‑приложения;
    • настройка docker-compose.yml для локального развёртывания;
    • определение сервисов (приложение, Nginx);
    • управление окружениями (dev/prod) через переменные окружения;
    • сборка и запуск контейнеров;
    • настройка томов и сетей для взаимодействия сервисов.

  6. Внедрение CI/CD на базе GitLab Actions

    Автоматизация процессов сборки, тестирования и развёртывания:

    • создание файла конфигурации .gitlab-ci.yml;
    • определение этапов пайплайна (build, test, lint, deploy);
    • настройка заданий для запуска юнит‑тестов и E2E‑тестов;
    • автоматизированная сборка Docker‑образов;
    • развёртывание в тестовую и продакшн‑среды;
    • настройка уведомлений о статусе сборок;
    • работа с секретами и переменными окружения в GitLab;
    • стратегии ветвления и триггеры для разных окружений (merge request, main branch).

  7. Заключение и рекомендации

    Итоги и направления дальнейшего развития:

    • подведение итогов выполненной миграции;
    • анализ достигнутых улучшений (производительность, масштабируемость, удобство поддержки);
    • рекомендации по мониторингу и логированию в новой инфраструктуре;
    • планы по дальнейшему развитию (добавление новых модулей, оптимизация производительности, расширение тестового покрытия);
    • чек‑лист для будущих миграций аналогичных проектов.