Так и не понял: FSM, Statecharts реализую автомат Мура или Милли?
Хороший вопрос! Не силен в теории автоматов, могу предположить что Мили, так как результирующий переход зависит от входящих данных и состояния. Но, могу быть не прав.
Далее, опущено рассмотрение конечных автоматов с памятью, позволяющих не только откат на какое-то предыдущее состояние как в статье, но и отложенные действия для запомненных состояний (разбор контекстно-зависимых грамматик к примеру).
Хорошее замечание. Настолько глубоко не использовал FSM, нужно разобраться в вопросе.
Statecharts - кмк, всего лишь "вложение" нескольких КА один в другой, возможно с единым "слушателем входного потока".
Тут только качественно можно оценить: контекст не должен дублировать логику из другого контекста; он должен быть автономен, то есть команда развивающая его не должна зависеть от других команд; ну и минимально возможное число внешних зависимостей, интеграций
Вы же говорите про массивы, json-ы, документы. Какие там записи, какие поля? И с какой радости индекс обновляется целиком?
Согласен, сумбурно написал. При обновлении или вставке данных, если затрагивается GIN индекс, происходит перестроение индекса, причем он перестраиватся не как простой b-tree см. тут https://postgrespro.ru/docs/postgrespro/16/gin-implementation, дословно, там же и по другим вопросам
Природа инвертированного индекса такова, что обновление GIN обычно медленная операция: при добавлении или изменении одной строки данных может потребоваться выполнить множество добавлений записей в индекс (для каждого ключа, извлечённого из индексируемого объекта).
Хранит список значений, содержащихся в колонке? Как вы себе это представляете? А btree не хранит?
Он не много по другому хранит данные, не как b-tree. Если для полнотекстового поиска, то он лексемы будет хранить
Добрый день! spring-boot-starter-oauth2-resource-server это стартер, он в себе содержит также зависимость spring-security-oauth2-resource-server, вы можете в этом убедиться, посмотрев зависимости, которые он загружает
Такой подход тоже часто используют. Если у вас сервисы хорошо защищены от запросов извне, то можно убрать security совсем из сервисов, так мы уберем дополнительную обязанность с микросервисов. Но в этом случае у вас Gateway становится бутылочным горлышком.
А как вы планируете разделять API по ролям по url запроса на gateway или в header класть информацию о роли пользователя?
Или различные точки входа(возможно разные API Gateway) для разных ролей пользователя?
Если большая система, то обязанность проверки и переадресации обычно возлагают на API Gateway. Но часто оставляют проверку на наличие токена и валидацию его подписи в самих сервисах, чтобы предотвратить, на всякий случай, несанкционированный доступ.
Спасибо за комментарий!
Хороший вопрос! Не силен в теории автоматов, могу предположить что Мили, так как результирующий переход зависит от входящих данных и состояния. Но, могу быть не прав.
Хорошее замечание. Настолько глубоко не использовал FSM, нужно разобраться в вопросе.
Да, это просто расширение.
Интересная метрика, в таком ключе не задумывался над этим. Спасибо!
Тут только качественно можно оценить: контекст не должен дублировать логику из другого контекста; он должен быть автономен, то есть команда развивающая его не должна зависеть от других команд; ну и минимально возможное число внешних зависимостей, интеграций
Согласен, сумбурно написал. При обновлении или вставке данных, если затрагивается GIN индекс, происходит перестроение индекса, причем он перестраиватся не как простой b-tree
см. тут https://postgrespro.ru/docs/postgrespro/16/gin-implementation, дословно, там же и по другим вопросам
Он не много по другому хранит данные, не как b-tree. Если для полнотекстового поиска, то он лексемы будет хранить
Добрый день!
spring-boot-starter-oauth2-resource-server это стартер, он в себе содержит также зависимость spring-security-oauth2-resource-server, вы можете в этом убедиться, посмотрев зависимости, которые он загружает
А как вы планируете разделять API по ролям по url запроса на gateway или в header класть информацию о роли пользователя?
Или различные точки входа(возможно разные API Gateway) для разных ролей пользователя?