не мы — как говорится в статье, технологию разработали в SoundCloud :)
на API Gateway BFF действительно похож — в некоторых источниках его называют вариацией этого паттерна. главное различие — BFF, как правило, ориентирован на один тип клиента. в результате такая архитектура оказывается проще, а модуль — легче
спасибо за вопросы. для МП у нас выставлено REST API, работаем по HTTP. Событий для мобильного клиента, они работают с нами как с синхронным API в виде запрос-ответ.
как любой инструмент, флаги нужно применять с умом — и продукт надо подготовить, и команду обучить. в прошлой статье мы приводили схему, как мы сами встроили флаги в микросервисную архитектуру — https://habr.com/ru/post/543420/
Неискушённым читателям можем ответить, что Kubernetes — оркестратор микросервисов, который призван автоматизировать поддержку пула микросервисов в рабочем состоянии :) Он обеспечивает их доступность, масштабируемость, балансировку нагрузки и т.д… А бизнес-логику он не хранит — для этого и нужны решения, про которые идёт речь в статье. Они используются непосредственно в исходном коде, чтобы упростить контроль бизнес-логики, отвечающей за распределение вызовов по микросервисам, т.е. по отдельным составным частям бизнес-процессов.
измерить очень легко – есть прямые затраты на создание и настройку одного микросервиса. с шаблоном это не занимает больше 1-2 часов от первых шагов до деплоя (пока без бизнес-логики)
сложнее измерить косвенные затраты, связанные с качеством, оно сильно зависит от самой команды и разработчиков в ней. если команда не ровная по навыкам, шаблон помогает выровнять картину, плюс компания быстрее получает результат от новичков.
создание новых микросервисов, переработки и обновления старых — разные истории, и для обновления шаблоны не подойдут.
что касается второй части вашего комментария, то у нас таких проблем не возникает, потому что шаблон используется для создания сервисов, а не подключается как библиотека
фича-флаги — тема для отдельной статьи, и в общем никто не спорит, что их можно подружить с гитфлоу. здесь же мы хотели сказать, что при прочих равных с TBD такие процессы выстроить проще, поскольку сам подход ориентирует на выпуск продукта микрорелизами
согласны, мы неточно выразились в тексте — такой вариант отчасти подразумевается в п.2: "разделение между арендаторами происходит на уровне инфраструктуры. Каждая группа пользователей заходит на свой URL или подключается к собственному серверу".
что касается проблем с бизнес-логикой, то они сильно сокращаются, если мультитенантность приложения закладывается изначально, на уровне архитектуры. если на эти рельсы переводить уже работающий продукт, то, да, код придётся изрядно перерыть
На самом деле не столь важно, какой из систем будет собираться конечный фреймворк.
Важно скорее то, как его подключать в качестве зависимости.
Если остановить свой выбор на Carthage, то можно воспользоваться поддержкой уже собранных зависимостей (Binary only frameworks), которые подтягиваются на основе файлов-спецификаций в формате JSON. Версионирование таких зависимостей немного отличается от работы с зависимостями, собираемыми из исходного кода, где конкретная версия библиотеки обозначается через релизный тэг в git. Разница в том, что версии зависимостей для Binary only frameworks определяются в файле-спецификации, а не на основе списка тэгов git.
Таким образом, для поддержки этой фичи Carthage при сборке библиотек на CI/CD системе, потребуется хранить и обновлять файл-спецификацию со списком собранных артефактов и ссылками на них.
Что касается хранения зависимостей в репозитории, тут возможны различные варианты.
Если делать этого не хочется, то можно оставить подтягивание зависимостей на совести Carthage на этапе сборки проекта. При этом, если хочется — не обязательно включать папку с подтянутыми зависимости в репозирий, читай включить её в .gitignore. Просто при каждой сборке проекта будет выполняться дополнительная операция по стягиванию/синхронизации зависимостей.
в некотором смысле, действительно сами — IDE-плагин и другие инструменты, которые мы упоминаем в тексте, сильно помогают автоматизировать процесс.
Мы не совсем свободны в выборе технологий, ориентируемся на стек заказчика. В частности, поэтому и Rabbit здесь используем
Также у нас ответы не просто клиент->RMQ->клиент, есть еще доп. рест вызовы, бизнес логика, маппинги всякие, БД
можно взглянуть и с другой стороны — BFF упрощает жизнь фронтендерам и помогает им отвязаться от многих процессов на бэкенде
не мы — как говорится в статье, технологию разработали в SoundCloud :)
на API Gateway BFF действительно похож — в некоторых источниках его называют вариацией этого паттерна. главное различие — BFF, как правило, ориентирован на один тип клиента. в результате такая архитектура оказывается проще, а модуль — легче
спасибо за вопросы. для МП у нас выставлено REST API, работаем по HTTP. Событий для мобильного клиента, они работают с нами как с синхронным API в виде запрос-ответ.
вот пока ссылка на наш радар с краткими описаниями всех технологий
это тянет на энциклопедию, мы подумаем, как продолжить эту тему
у нас было несколько постов на эту тему:
про Azure DevOps в целом — https://habr.com/ru/post/547906/
про шаблон проекта — https://habr.com/ru/post/552692/
инструменты проектной аналитики — https://habr.com/ru/post/553528/
как любой инструмент, флаги нужно применять с умом — и продукт надо подготовить, и команду обучить. в прошлой статье мы приводили схему, как мы сами встроили флаги в микросервисную архитектуру — https://habr.com/ru/post/543420/
спасибо за комментарий, об этом мы подробно расскажем в следующем посте.
Неискушённым читателям можем ответить, что Kubernetes — оркестратор микросервисов, который призван автоматизировать поддержку пула микросервисов в рабочем состоянии :) Он обеспечивает их доступность, масштабируемость, балансировку нагрузки и т.д… А бизнес-логику он не хранит — для этого и нужны решения, про которые идёт речь в статье. Они используются непосредственно в исходном коде, чтобы упростить контроль бизнес-логики, отвечающей за распределение вызовов по микросервисам, т.е. по отдельным составным частям бизнес-процессов.
да, тема интересная и богатая, постараемся в будущем вернуться к ней, погрузиться в детали.
измерить очень легко – есть прямые затраты на создание и настройку одного микросервиса. с шаблоном это не занимает больше 1-2 часов от первых шагов до деплоя (пока без бизнес-логики)
сложнее измерить косвенные затраты, связанные с качеством, оно сильно зависит от самой команды и разработчиков в ней. если команда не ровная по навыкам, шаблон помогает выровнять картину, плюс компания быстрее получает результат от новичков.
создание новых микросервисов, переработки и обновления старых — разные истории, и для обновления шаблоны не подойдут.
что касается второй части вашего комментария, то у нас таких проблем не возникает, потому что шаблон используется для создания сервисов, а не подключается как библиотека
вот ссылки, которыми пользовался автор шаблона:
1) https://docs.microsoft.com/en-us/visualstudio/extensibility/how-to-use-wizards-with-project-templates?view=vs-2019 — пример от MS
2) https://github.com/dogtail9/ProjectTemplateTutorial — готовый пример с кучей полезного кода
3) https://stackoverflow.com/questions/60294380/is-there-a-way-to-add-conditions-in-vstemplates-or-a-way-to-generate-output-pro — по сути создаем Solution из разных шаблонов
спасибо за наводку на cookiecutter — изучим
мы используем стандартные функции Visual Studio для создания шаблонов с помощью текстовых шаблонов T4. распространение через маркетплейс утилит для Visual Studio — создаем VSIX-расширение, устанавливаем шаблон прямо в VS. у нас приватный репозиторий, при желании можно загрузить прямо в маркетплейс Microsoft — https://docs.microsoft.com/en-us/visualstudio/extensibility/walkthrough-publishing-a-visual-studio-extension?view=vs-2019
мы смотрели рынок, но в подробности выбора углубляться не будем, чтобы не было холиваров.
фича-флаги — тема для отдельной статьи, и в общем никто не спорит, что их можно подружить с гитфлоу. здесь же мы хотели сказать, что при прочих равных с TBD такие процессы выстроить проще, поскольку сам подход ориентирует на выпуск продукта микрорелизами
согласны, мы неточно выразились в тексте — такой вариант отчасти подразумевается в п.2: "разделение между арендаторами происходит на уровне инфраструктуры. Каждая группа пользователей заходит на свой URL или подключается к собственному серверу".
что касается проблем с бизнес-логикой, то они сильно сокращаются, если мультитенантность приложения закладывается изначально, на уровне архитектуры. если на эти рельсы переводить уже работающий продукт, то, да, код придётся изрядно перерыть
пожалуйста)
На самом деле не столь важно, какой из систем будет собираться конечный фреймворк.
Важно скорее то, как его подключать в качестве зависимости.
Если остановить свой выбор на Carthage, то можно воспользоваться поддержкой уже собранных зависимостей (Binary only frameworks), которые подтягиваются на основе файлов-спецификаций в формате JSON. Версионирование таких зависимостей немного отличается от работы с зависимостями, собираемыми из исходного кода, где конкретная версия библиотеки обозначается через релизный тэг в git. Разница в том, что версии зависимостей для Binary only frameworks определяются в файле-спецификации, а не на основе списка тэгов git.
Таким образом, для поддержки этой фичи Carthage при сборке библиотек на CI/CD системе, потребуется хранить и обновлять файл-спецификацию со списком собранных артефактов и ссылками на них.
Что касается хранения зависимостей в репозитории, тут возможны различные варианты.
Если делать этого не хочется, то можно оставить подтягивание зависимостей на совести Carthage на этапе сборки проекта. При этом, если хочется — не обязательно включать папку с подтянутыми зависимости в репозирий, читай включить её в .gitignore. Просто при каждой сборке проекта будет выполняться дополнительная операция по стягиванию/синхронизации зависимостей.