Вы это в итоге решали на уровне собственной state-machine поверх Open WebUI или именно это и стало одной из причин перехода к другому UI-слою?
Это стало одной из главных причин перехода к assistamt-ui - про это подробнее рассказали во второй части, можно посмотреть статью в профиле.
И ещё интересно, где у вас хранится source of truth по состоянию такого процесса: внутри LangGraph state/checkpointing или отдельно во внешнем storage, чтобы UI мог безопасно восстанавливать текущий этап после паузы?
Чекпоинты для восстановления после прерываний мы храним в памяти процесса, отдельно в mongo db мы после каждого узгла сохраняли для логов все состояние. Когда мы добавляли чекпоинты, в основном пакете langgraph mongo не поддерживалась, и в целом это mvp, поэтому пока in-memory чекпоинтер. В планах было переходить на postgres и сохранять все туда, он официально поддерживается.
Сессии действительно хранятся в БД, но Infinispan остается обязательным: он кэширует эти же сессии и часть данных которые в БД не попадают, например authenticationSessions, loginFailures, actionTokens. Также через реплицируемый кэш work узлы рассылают друг другу инвалидацию локальных кэшей – realms, users, authorization, keys, crl, иначе после изменений на одном узле остальные продолжали бы отдавать устаревшие данные
спасибо за вопросы! 1- По поводу выбора Sentry обосновали в тексте:
“Когда появляется стандарт OpenTelemetry, следующий вопрос — куда отправлять собранные данные. Для анализа трейсов часто используют Jaeger. Но у заказчика в инфраструктуре уже был Sentry, поэтому мы остановились на привычном для заказчика решении вместо внедрения чего-то нового.”
Плюс прелесть OpenTelemetry в том что мы можем легко использовать несколько инструментов для хранения и анализа или быстро менять один на другой.
2- Проект не самый нагруженный, за две недели у на около 5 миллионов трейсов
Да, имеем в виду не полную миграцию с помощью ИИ, а изменение рутинных правок, что ускорило ручной перенос. В статье при этом указали причины, почему нельзя скормить весь код и сделать переход. Cypress используем, так как это общепринятый инструмент, но в настоящее время все больше и больше переходим на Playwright.
добрый день! учесть все сразу в одном прогоне нереально, потому что там могут быть как условный 0, так и 99..9 Но периодическое попадание в разные места вполне возможно, учитывая то, что мы тестируем UI, и динамические данные скорее имитируют реального пользователя, который с некоторой вероятностью может сделать необычное действие
Если рассматривать отказ от Expo в уже существующем проекте, то это будет трудный процесс, так как придётся пересматривать зависимости, искать что-то подходящее и обновлять код.
Если отказываться именно от инфраструктуры EAS, то здесь проблем больших не будет, если есть знание, как собираются приложения для android/ios, как публикуются приложения в сторы. EAS позволяет не заботиться о том как собирается приложение, как оно публикуется или обновляется, это всё настраивается один раз, а дальше делается по нажатию кнопок) Без EAS просто придётся делать всё вручную
не мы — как говорится в статье, технологию разработали в SoundCloud :)
на API Gateway BFF действительно похож — в некоторых источниках его называют вариацией этого паттерна. главное различие — BFF, как правило, ориентирован на один тип клиента. в результате такая архитектура оказывается проще, а модуль — легче
спасибо за вопросы. для МП у нас выставлено REST API, работаем по HTTP. Событий для мобильного клиента, они работают с нами как с синхронным API в виде запрос-ответ.
как любой инструмент, флаги нужно применять с умом — и продукт надо подготовить, и команду обучить. в прошлой статье мы приводили схему, как мы сами встроили флаги в микросервисную архитектуру — https://habr.com/ru/post/543420/
Это стало одной из главных причин перехода к assistamt-ui - про это подробнее рассказали во второй части, можно посмотреть статью в профиле.
Чекпоинты для восстановления после прерываний мы храним в памяти процесса, отдельно в mongo db мы после каждого узгла сохраняли для логов все состояние. Когда мы добавляли чекпоинты, в основном пакете langgraph mongo не поддерживалась, и в целом это mvp, поэтому пока in-memory чекпоинтер. В планах было переходить на postgres и сохранять все туда, он официально поддерживается.
спасибо, учтем дальше в работе!
Сессии действительно хранятся в БД, но Infinispan остается обязательным: он кэширует эти же сессии и часть данных которые в БД не попадают, например authenticationSessions, loginFailures, actionTokens. Также через реплицируемый кэш work узлы рассылают друг другу инвалидацию локальных кэшей – realms, users, authorization, keys, crl, иначе после изменений на одном узле остальные продолжали бы отдавать устаревшие данные
В релизе 26.4 появился “Keycloak cluster health check”. Отдельно включать не нужно, но отображается, если keycloak в режиме кластера, вот issue Detect and handle KC split brain clusters · Issue #41561 · keycloak/keycloak, вот PR Detect and handle KC split brain clusters by pruivo · Pull Request #41730 · keycloak/keycloak
спасибо за вопрос, здесь под сервисом имеем ввиду микросервис
спасибо за вопросы! 1- По поводу выбора Sentry обосновали в тексте:
“Когда появляется стандарт OpenTelemetry, следующий вопрос — куда отправлять собранные данные. Для анализа трейсов часто используют Jaeger. Но у заказчика в инфраструктуре уже был Sentry, поэтому мы остановились на привычном для заказчика решении вместо внедрения чего-то нового.”
Плюс прелесть OpenTelemetry в том что мы можем легко использовать несколько инструментов для хранения и анализа или быстро менять один на другой.
2- Проект не самый нагруженный, за две недели у на около 5 миллионов трейсов
спасибо, что заметили! действительно, получается иронично. заменим скриншоты как можно скорее в хорошем разрешении. еще раз спасибо за сигнал)
Да, имеем в виду не полную миграцию с помощью ИИ, а изменение рутинных правок, что ускорило ручной перенос. В статье при этом указали причины, почему нельзя скормить весь код и сделать переход.
Cypress используем, так как это общепринятый инструмент, но в настоящее время все больше и больше переходим на Playwright.
добрый день! учесть все сразу в одном прогоне нереально, потому что там могут быть как условный 0, так и 99..9
Но периодическое попадание в разные места вполне возможно, учитывая то, что мы тестируем UI, и динамические данные скорее имитируют реального пользователя, который с некоторой вероятностью может сделать необычное действие
Если рассматривать отказ от Expo в уже существующем проекте, то это будет трудный процесс, так как придётся пересматривать зависимости, искать что-то подходящее и обновлять код.
Если отказываться именно от инфраструктуры EAS, то здесь проблем больших не будет, если есть знание, как собираются приложения для android/ios, как публикуются приложения в сторы. EAS позволяет не заботиться о том как собирается приложение, как оно публикуется или обновляется, это всё настраивается один раз, а дальше делается по нажатию кнопок) Без EAS просто придётся делать всё вручную
в некотором смысле, действительно сами — 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/
спасибо за комментарий, об этом мы подробно расскажем в следующем посте.