Для поддержки пользователей через интернет портал Deutsche-Telekom используется чат бот FragMagenta.
Архитектура микросервисная, исторически контейнеры либо на Java, либо на Python Django. Для легковесности решили добавить и контейнеры в NodeJS, но возникла проблема с вызовом версии такого своего NodeJS компонента.
Если взять библиотечный пакет, то для управления версиями имеются удобные инструменты через package.json. Но для своих локально развёртываемых компонентов тоже нужно иметь возможность не только обратиться к новейшей версии сервиса, но и к предыдущим версиям этого сервиса и при этом иметь возможность удобного доступа к патчам заданных версий. Как выяснилось пакет express-version-route удобен для этой цели, а с предложенной и одобренной версией v1.2.0 стал ещё удобнее.
В чём же была проблема? Хотелось, во-первых, иметь достаточно единообразный и без дубликатов рутинг по версиям, т.е. когда для версии сервиса 1.3.5 вызывается класс в папке с суффиксом 1.3.5, и не нужно прописывать отдельный рутинг для версии 1.3 либо 1, во-вторых, для вызова с версией 1.3 вызывается сервис с максимальным патчем.
Пакет semver предлагает для вызова патчей синтаксис вида:
Но во-первых, в имплементации пакета express-version-route роутинг идёт на первую подходящую версию и тогда рутинг будет зависеть от порядка добавления записей в routesMap.
Во-вторых, сам подход заполнения routesMap предполагает добавлять дополнительную логику с саму таблицу рутинга:
Предложенное решение, ставшее версией v1.2.0 пакета express-version-route упрощает и таблицу рутинга и способ вызова патча. А именно вызывая sms_to_customer.cloud.telekom.de/send/v1.2 мы получим наибольшую версию для всего v1.2.* набора. Например, это v1.2.3
Тест выглядит так:
Само же предложенное и внедрённое решение добавляет вариант поиска максимального патча среди всей таблицы рутинга именно в случае дополнительного параметра:
Это был интересный опыт поучаствовать в улучшении Open Source кода.
Если у вас есть вопросы, пишите в комментариях, буду рад ответить на них.
Архитектура микросервисная, исторически контейнеры либо на Java, либо на Python Django. Для легковесности решили добавить и контейнеры в NodeJS, но возникла проблема с вызовом версии такого своего NodeJS компонента.
Если взять библиотечный пакет, то для управления версиями имеются удобные инструменты через package.json. Но для своих локально развёртываемых компонентов тоже нужно иметь возможность не только обратиться к новейшей версии сервиса, но и к предыдущим версиям этого сервиса и при этом иметь возможность удобного доступа к патчам заданных версий. Как выяснилось пакет express-version-route удобен для этой цели, а с предложенной и одобренной версией v1.2.0 стал ещё удобнее.
В чём же была проблема? Хотелось, во-первых, иметь достаточно единообразный и без дубликатов рутинг по версиям, т.е. когда для версии сервиса 1.3.5 вызывается класс в папке с суффиксом 1.3.5, и не нужно прописывать отдельный рутинг для версии 1.3 либо 1, во-вторых, для вызова с версией 1.3 вызывается сервис с максимальным патчем.
Пакет semver предлагает для вызова патчей синтаксис вида:
Но во-первых, в имплементации пакета express-version-route роутинг идёт на первую подходящую версию и тогда рутинг будет зависеть от порядка добавления записей в routesMap.
Во-вторых, сам подход заполнения routesMap предполагает добавлять дополнительную логику с саму таблицу рутинга:
Предложенное решение, ставшее версией v1.2.0 пакета express-version-route упрощает и таблицу рутинга и способ вызова патча. А именно вызывая sms_to_customer.cloud.telekom.de/send/v1.2 мы получим наибольшую версию для всего v1.2.* набора. Например, это v1.2.3
Тест выглядит так:
Само же предложенное и внедрённое решение добавляет вариант поиска максимального патча среди всей таблицы рутинга именно в случае дополнительного параметра:
Это был интересный опыт поучаствовать в улучшении Open Source кода.
Если у вас есть вопросы, пишите в комментариях, буду рад ответить на них.