Это связано с тем, что данные денормализованы и не требуют дорогостоящих соединений между таблицами.
Денормализация денормализации рознь. Есть кейсы, когда нормализация наоборот ускоряет манипуляции с данными.
Для монги главный фактор для использования: требуется дешевое горизонтальное масштабирование. Во всех остальных случаях: стоит подумать нужна ли реально монга, потому что потом будет больно с нее съезжать, т.к. честный ACID снимает кучу головняков, не только для "денежных" сервисов.
Не слушайте никого. Nginx подходит для абсолютного большинства задач Load Balancing, Reverse Proxy для абсолютного большинства систем. Шило на мыло в общем. Есть некоторое небольшое количества задач и систем, в которых вместо Nginx действительно лучше использовать его альтернативы.
получение нового рефреш-токена должно быть идемпотентным
справедливости ради, повторное обновление рефреш-токена ограничивают из-за безопасности. на случай, если его получил злоумышленник. и что лучше, идемпотентность обновления рефреш-токена или безопасность - еще не решили.
Все беда в том, что многие думают, что микросервисы - это ответ на решение технических проблем.
Нет. Микросервисы - это ответ на проблемы масштабирования команд разработки. И основной критерий микросервисности - за один микросервис отвечает ровно одна команда. И соответственно, каждая команда пилит свой сервис без оглядки на другие команды, ответственность только на уровне контракта по API. Если одна команда может пилить большой сервис, aka монолит, и бизнес устраивает скорость поставки - все замечательно, пилим монолит.
Согласен. Любые предложения, начинающиеся со смены стандартного порта, лично я дальше не читаю. Это маркер, что люди не совсем понимают сетевые реалии. Настоятельно рекомендую всем остальным поступать также.
забыл добавить, один backend не означает, что физически один backend. там может быть пачка микросервисов, которые пилит пачка backend-команд. и все данные бесшовно склеиваются через федерацию. как там распилины данные по микросервисам, фронтам знать неинтересно, они видят схему и запрашивают данные.
да, все эти удобства не достаются бесплатно. расплачиваться приходится всем, что упомянуто в статье в качестве недостатков: проблема N+1, сложностью отладки при отсутствии детального логирования и трейсинга, вопросы по безопасности
Верно. GraphQL проявляет себя на достаточно больших проектах. На которых несколько каналов, условно веб, андроид, ios и один backend. И активная поставка изменений в ui на все каналы.
И тем не менее, в любой профессии есть люди, которые в 10 раз более эффективны, чем в среднем по отрасли. Да, таких мало. Да, эффективны в самом широком смысле этого слова.
Если у вас непредсказуемая или предсказуемо плавающая нагрузка в широких пределах, из-за чего для обеспечения нужных мощностей на пиках, вам необходимо держать резерв своих мощностей. При таком раскладе, возможно, использование облачных мощностей будет выгоднее.
Каждый, конечно, сам себе "хозяин - барин". Но такой подход с перевыпуском access-токенов под капотом микросервисов - это полное переосмысление подхода access-, refresh-токенов в сторону радикального ухудшения.
Refresh-токены, идеологически, должны быть на стороне клиента. Ну в крайнем случае, на стороне API Gateway'я. Передавать refresh-токены в сервисы, это все равно что передавать в сервисы логин/пароль пользователя.
Если сервисы используют скоуп из клиентского access-токена, то тут два подхода, либо сервисы оперируют своими сервисными access-токенами, либо обеспечиваем жизнь клиентского access-токена на все время жизни обработки запроса (а это не всегда означает наличие жесткой проверки exp > current time).
зы
справедливости ради, стоить отметить, что я регулярно встречаю подобные подходы ;)
Как у Squidex дела с GraphQL Federation?
Денормализация денормализации рознь.
Есть кейсы, когда нормализация наоборот ускоряет манипуляции с данными.
Для монги главный фактор для использования: требуется дешевое горизонтальное масштабирование. Во всех остальных случаях: стоит подумать нужна ли реально монга, потому что потом будет больно с нее съезжать, т.к. честный ACID снимает кучу головняков, не только для "денежных" сервисов.
Не слушайте никого. Nginx подходит для абсолютного большинства задач Load Balancing, Reverse Proxy для абсолютного большинства систем. Шило на мыло в общем.
Есть некоторое небольшое количества задач и систем, в которых вместо Nginx действительно лучше использовать его альтернативы.
реальные внедренцы САПа думают немного по другому
справедливости ради, повторное обновление рефреш-токена ограничивают из-за безопасности. на случай, если его получил злоумышленник. и что лучше, идемпотентность обновления рефреш-токена или безопасность - еще не решили.
Все беда в том, что многие думают, что микросервисы - это ответ на решение технических проблем.
Нет. Микросервисы - это ответ на проблемы масштабирования команд разработки. И основной критерий микросервисности - за один микросервис отвечает ровно одна команда. И соответственно, каждая команда пилит свой сервис без оглядки на другие команды, ответственность только на уровне контракта по API.
Если одна команда может пилить большой сервис, aka монолит, и бизнес устраивает скорость поставки - все замечательно, пилим монолит.
Похоже вы переизобрели OIDC Device Authorization.
Согласен. Любые предложения, начинающиеся со смены стандартного порта, лично я дальше не читаю. Это маркер, что люди не совсем понимают сетевые реалии. Настоятельно рекомендую всем остальным поступать также.
Для полноты картины: https://apiblueprint.org/
Вижу скрины с кодом, сразу ставлю плюс!
Camunda плохо дружит с подходом gitops.
Тем более речь и критичных процессах, связанных с безопасностью.
забыл добавить, один backend не означает, что физически один backend. там может быть пачка микросервисов, которые пилит пачка backend-команд. и все данные бесшовно склеиваются через федерацию. как там распилины данные по микросервисам, фронтам знать неинтересно, они видят схему и запрашивают данные.
да, все эти удобства не достаются бесплатно. расплачиваться приходится всем, что упомянуто в статье в качестве недостатков: проблема N+1, сложностью отладки при отсутствии детального логирования и трейсинга, вопросы по безопасности
Верно. GraphQL проявляет себя на достаточно больших проектах. На которых несколько каналов, условно веб, андроид, ios и один backend. И активная поставка изменений в ui на все каналы.
Предположительно, касандру записали в колоночные базы из-за термина "column-family"
Это очень похоже на "column-oriented", но не одно и тоже
И тем не менее, в любой профессии есть люди, которые в 10 раз более эффективны, чем в среднем по отрасли. Да, таких мало. Да, эффективны в самом широком смысле этого слова.
Если у вас непредсказуемая или предсказуемо плавающая нагрузка в широких пределах, из-за чего для обеспечения нужных мощностей на пиках, вам необходимо держать резерв своих мощностей. При таком раскладе, возможно, использование облачных мощностей будет выгоднее.
Есть легаси системы, где права раздают в зависимости от OU.
Использовать процессный движок - (жирное) да.
Использовать Camunda для idm-процессов - нет.
Есть ли процессные движки, кроме Camunda - конечно есть.
да ну что вы, право боже.
Базы данных внутри кубера - это же надежно, все так делают ;)
Каждый, конечно, сам себе "хозяин - барин".
Но такой подход с перевыпуском access-токенов под капотом микросервисов - это полное переосмысление подхода access-, refresh-токенов в сторону радикального ухудшения.
Refresh-токены, идеологически, должны быть на стороне клиента. Ну в крайнем случае, на стороне API Gateway'я. Передавать refresh-токены в сервисы, это все равно что передавать в сервисы логин/пароль пользователя.
Если сервисы используют скоуп из клиентского access-токена, то тут два подхода, либо сервисы оперируют своими сервисными access-токенами, либо обеспечиваем жизнь клиентского access-токена на все время жизни обработки запроса (а это не всегда означает наличие жесткой проверки exp > current time).
зы
справедливости ради, стоить отметить, что я регулярно встречаю подобные подходы ;)