Зачем нам Node.js или Angular на бэкенде

Всем привет! Меня зовут Александр, я разрабатываю low-code платформу Eftech.Factory в компании Effective Technologies. В этой статье я хочу поделиться тем, как и почему в стеке нашего продукта появился Node.js. Рассмотрим одно из основных преимуществ Node.js (внезапно это JavaScript) и то, как он помогает нам сэкономить время в два раза на разработку и сопровождение.

Из-за названия статьи может возникнуть путаница: чаще всего, когда речь идет об Angular на бэкенде, подразумевается Server Side Rendering (SSR). Однако в данной статье мы не будем обсуждать SSR, а сосредоточимся на переиспользовании кода и использовании Angular на бэкенде. Давайте начнем! 

Какие бы классные и интересные приложения мы ни создавали, все они требуют получения данных — от пользователей, других систем или даже датчиков автоматизации. Важным аспектом этого процесса является корректность получаемых данных, так как она критически важна для их обработки и служит залогом успешного результата работы программы.

Зачем нам Node.js? 

Всё начинается с задачи обработки данных. Команда аналитиков формулирует требования к данным, в том числе и требования к проверке этих данных.  На самом деле, мы сталкиваемся с двумя задачами: задача для фронтенда, чтобы наш интерфейс был отзывчивым и удобным, и задача для бэкенда, чтобы наше приложение было безопасным и надежным. Не стоит спрашивать, почему нельзя ограничиться проверками только на фронтенде — надеюсь, вы так не делаете! =) 

Чаще всего эти задачи передаются бэкенд и фронтенд разработчикам, которые реализуют одну и ту же логику. И вот тут мы подходим к главному аргументу в пользу использования Node.js: проверки на фронтенде мы реализуем на TypeScript, так почему бы не использовать те же проверки и на бэкенде? Преимущества очевидны:

1. Экономия времени и ресурсов — нам больше не нужно писать два раза одну и ту же валидацию;

2. Отсутствие рассинхрона валидации — когда в требования вносятся изменения, а ресурса одного из направлений недостаточно, мы можем столкнуться с задержками. Если не уследить за процессом, это может привести к возникновению багов; 

3. Единое поведение реализации — например, в разных языках могут  быть по-разному реализованы работа с числами: округление, переполнение и другие нюансы.

Таким образом, использование единого подхода к валидации на фронтенде и бэкенде не только упрощает процесс разработки, но и делает его более надёжным.

Что же делать с Angular?

Вижу цель — иду к ней! На фронтенде мы используем  Angular, а на бэкенде разнообразие сервисов из PHP и Golang. Как же нам реализовать единую валидацию? Ответ на поверхности — переписать PHP сервисы на Node.js и использовать код с фронтенда. Однако всё не так просто. Чтобы переиспользовать код с фронтенда, необходимо соблюсти несколько условий в реализации:

• Angular — тут нужно отметить, что архитектура Angular является одной из причин, по которой мы его выбрали. У Angular понятные модули, готовая система внедрения зависимостей (DI) и достаточно мощные реактивные формы, которые можно переиспользовать независимо от DOM и API браузера. Именно это мы и сделали.

• Структура данных — нам нужно единое описание структуры данных и правил ее проверки. Это может быть описание цепочки валидаторов для полей. В нашем случае, в low-code на базе JSON Schema, мы описываем элементы UI, в которых есть блок validation с правилами проверок, реализованных с помощью небольших функций, которые мы называем helper. Почему мы не валидируем по JSON Schema? Дело в том,  что не всегда структура данных соответствует UI, а сами проверки могут быть весьма сложными.

• Логика проверок также должна обладать определенным уровнем абстракций и не иметь прямых зависимостей от того или иного окружения. Все зависимости от API браузера и Node.js мы выносим в слой сервисов и передаем через dependency injection (DI — внедрение зависимостей), Таким образом, с помощью DI мы можем переопределять поведение сервиса или целого валидатора.  Когда это может понадобиться? Например, если  мы хотим проверить существование записи: на фронтенде мы делаем HTTP-запрос, а на бэкенде  — запрос к базе данных.  Для этого мы выносим FindObject как зависимость c соответствующими реализациям на фронтенде и бэкенде для ExistValidator. 

Рассмотрим, как это работает на практике:

Нам понадобится единое описание проверок данных. В нашем случае это описание хранится в low-code:

{  "@title": "Добавление пользователя",  "type": "object",  "properties": {    "email": {      "type": "string",      "validation": [        {          "rule": {            "$match": {              "pattern": "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{1,1000}$"            }          },          "message": "Некорректный адрес электронной почты",          "events": [            "onUpdate",            "onBackend"          ]        },        {          "rule": {            "$api-data": {              "query": "user/email_exists"            }          },          "message": "Пользователь с таким адресом электронной почты уже зарегистрирован в системе",          "events": [            "onBackend"          ]        }      ]    }  } }

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

Если реализацию проверки хелпером $match мы можем переиспользовать без каких либо изменений за счет использования String.match(), то с хелпером $api-data все немного сложнее — в обоих случаях и с фронтенда, и с бэкенда отправляется HTTP-запрос в сервис данных, но на фронтенде у нас реализация запроса на HttpClient от Angular, а на бэкенде undici. 

Реализация самого хелпера не будет отличаться на фронтенде и бэкенде, чтобы его использовать мы помечаем класс для dependency injector Angular с помощью декоратора Injectable. На бэкенде мы используем NestJS, соответственно для бэкенда мы также помечаем класс для DI с помощью декоратора InjectableGlobal, который мы позаимствовали из NestJS для исключения коллизии в именовании. 

@Injectable({  providedIn: 'root', }) @InjectableGlobal() export class ApiDataHelper<T> implements Helper {   constructor(protected http: HttpClient) {}   apply(options: unknown, context: unknown): Observable<T> {} }

Важно отметить, что использование NestJS очень упрощает задачу по работе с зависимостями. Ранее мы использовали реализацию ReflectiveInjector из Angular в сервисах на Node.js, однако начиная с 16-й версии ее удалили.

Теперь добавим на бэкенде класс, совместимый по API  с HttpClient

Injectable() @InjectableGlobal() export class HttpService<T> {    public get(url, options?: HttpOptions): Observable<T> {}     public post(url, body?: unknown, options: HttpOptions = {}): Observable<T> {} }

Останется только переопределить соответствующий класс в модуле NestJS на бэкенде:

@Module({  providers: [    {      provide: BaseHttpService,      useValue: HttpService,    },  ], }) export class ApiModule {}

Поздравляю! У нас готова реализация, которую осталось только применить. Здесь нам на помощь придут реактивные формы Angular. Результаты работы хелперов  обернуты в RxJS потоки, что позволяет использовать их без каких-либо изменений в asyncValidators контролов Angular:

control.setAsyncValidators(validators)

На бэкенде также необходимо создать контролы, заполнить их значениями и проверить результат валидации:

validate(  schema: Schema,  data: unknown,  path = '/',  context: ApplyContext ): Observable<ValidateResult> {    // Cоздаем форму из контролов ангуляр    let form = this.schemaService.create(schema, context);     // Заполняем данные из POST    form.reset(data);     return form.statusChanges.pipe(      startWith(form.status),      filter((status) => status !== 'PENDING'),      map(() => {        // Формируем ответ с ошибками, если они есть        const errors = this.buildErrors(form);         return this.buildResponse(form, data, errors);      })    ); } 

Стоит отметить, что  schemaService имеет единую реализацию как для фронтенда, так и для бэкенда по построению реактивной формы и установке валидации. В случае успешной проверки сервис выполняет целевой запрос на сохранение данных; если валидация не прошла, то в ответе возвращается список ошибок, которые отобразятся на форме пользователя для исправления.

Что в итоге?

Angular упрощает создание реактивных форм и клиентскую валидацию, благодаря чему пользователи сразу видят сообщения об ошибках. Это, в свою очередь, делает взаимодействие с приложением более удобным и интуитивно понятным. На сервере валидация также помогает нам контролировать целостность данных, исключая дублирование кода и экономя время.

Используя Node.js на бэкенде и Angular на фронтенде, мы минимизируем повторяющийся код, ускоряем разработку и добиваемся согласованности между клиентской и серверной частями приложения. Такой подход не только упрощает разработку, но и делает приложение более надежным и легким в поддержке.