забыл добавить, один backend не означает, что физически один backend. там может быть пачка микросервисов, которые пилит пачка backend-команд. и все данные бесшовно склеиваются через федерацию. как там распилины данные по микросервисам, фронтам знать неинтересно, они видят схему и запрашивают данные.
да, все эти удобства не достаются бесплатно. расплачиваться приходится всем, что упомянуто в статье в качестве недостатков: проблема N+1, сложностью отладки при отсутствии детального логирования и трейсинга, вопросы по безопасности
Верно. GraphQL проявляет себя на достаточно больших проектах. На которых несколько каналов, условно веб, андроид, ios и один backend. И активная поставка изменений в ui на все каналы.
И тем не менее, в любой профессии есть люди, которые в 10 раз более эффективны, чем в среднем по отрасли. Да, таких мало. Да, эффективны в самом широком смысле этого слова.
Если у вас непредсказуемая или предсказуемо плавающая нагрузка в широких пределах, из-за чего для обеспечения нужных мощностей на пиках, вам необходимо держать резерв своих мощностей. При таком раскладе, возможно, использование облачных мощностей будет выгоднее.
Каждый, конечно, сам себе "хозяин - барин". Но такой подход с перевыпуском access-токенов под капотом микросервисов - это полное переосмысление подхода access-, refresh-токенов в сторону радикального ухудшения.
Refresh-токены, идеологически, должны быть на стороне клиента. Ну в крайнем случае, на стороне API Gateway'я. Передавать refresh-токены в сервисы, это все равно что передавать в сервисы логин/пароль пользователя.
Если сервисы используют скоуп из клиентского access-токена, то тут два подхода, либо сервисы оперируют своими сервисными access-токенами, либо обеспечиваем жизнь клиентского access-токена на все время жизни обработки запроса (а это не всегда означает наличие жесткой проверки exp > current time).
зы
справедливости ради, стоить отметить, что я регулярно встречаю подобные подходы ;)
Представьте, вы заказали пиццу. И для вас "почти доставили" эквивалентно "не доставили". Пиццу вы кушать не можете. Пусть даже доставщик уже у вас во дворе. Конечно, вам может и будет греть душу тот факт, что уже "почти доставили", но сыты этим фактом вы не будете.
Пример, где event-sourcing себя проявляет с хорошей стороны.
Там где нужно правильно считать деньги, уже выше обсудили, event-sourcing не подходит.
Но там, где есть highload, и нет жестких требований по одномоментной консистентности, event-sourcing весьма полезен. Например, в твите надо показывать количество лайков и репостов. Для показа твита, данные извлечаются из какого-нибудь очень быстрого на чтение хранилища. А лайки и репосты складываем к отдельное очень быстрое на вставку хранилище. Затем отдельным процессом обновляем лайки и репосты.
В итоге, держим большую нагрузку с минимальными издержками. И с некоторой точностью показываем кол-во лайков и репостов.
это избыточно. надо обеспечить синхронность настроек сеттера поколений и консьюмеров, ориентирующихся на поколения. плюс мониторинг зависших сообщений в кафке.
различные curcuit breaker, throttling, rate limiter, custom idp, token validators, и прочее, что так или иначе регулярно требуется при выставлении публичного api
факторинг для юриков. здесь покупатель физик. ну и риски считают по разному, в факторинге смотрят на обороты юрика. здесь на физика смотрят как на ... (хз как смотрят, наверно как на физика-заемщика, но беззалоговые кредиты дорогие, на комиссии в 50$ с каждой покупки в 1000$ не проживешь имхо).
Вам надо всего лишь поработать на уже долго живущем проекте, и некоторое время фиксить на нем баги и пилить новые фичи. Где сменились поколения разрабов.
Когда из-за неудачного нейминга, вы полдня ковыряли код, чтобы понять его логику...
После этого полезность правильного нейминга перестанет быть неочевидной. И про сопроводительный текст для коммитов тоже самое.
Увы, бережливое производство не про склады и производство по запросу.
Бережливое производство про процесс непрерывного улучшения. Улучшения чего угодно, что влияет на результат производства. Если долго и целенаправленно улучшать, это дает результат. И это называется "увеличивает производительность", т.е. в единицу времени создается больше полезного.
Точно также как agile не про дейлики и спринты. А про взаимодействие бизнеса и команды, команды между собой, и опять же про процесс непрерывного улучшения. С целью "увеличения производительности".
И как и любая другая деятельность, это (внедрение бережливого производства, например) может быть успешно проведено. А может быть проведено для галочки, или даже во вред.
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).
зы
справедливости ради, стоить отметить, что я регулярно встречаю подобные подходы ;)
Все зависит от контекста.
Представьте, вы заказали пиццу.
И для вас "почти доставили" эквивалентно "не доставили". Пиццу вы кушать не можете. Пусть даже доставщик уже у вас во дворе. Конечно, вам может и будет греть душу тот факт, что уже "почти доставили", но сыты этим фактом вы не будете.
;) вот про это тезис про "почти сделано".
Раз уж мы говорим про микросервисы, то для полноты картины, можно еще добавить OAuth API Gateway, например в лице Gogatekeeper.
А всего лишь надо стандартизировать ответ ошибки, чтобы он включал в себя имя точки отказа и кодифицированную причину ошибки. В теле или заголовках.
Согласитесь, поведение клиента сильно отличается в случае ответа Too many requests, и в случае ответа Unauthorized.
А для бизнес-ошибок лучше возвращать 422 Unprocessable Entity.
Пример, где event-sourcing себя проявляет с хорошей стороны.
Там где нужно правильно считать деньги, уже выше обсудили, event-sourcing не подходит.
Но там, где есть highload, и нет жестких требований по одномоментной консистентности, event-sourcing весьма полезен. Например, в твите надо показывать количество лайков и репостов. Для показа твита, данные извлечаются из какого-нибудь очень быстрого на чтение хранилища. А лайки и репосты складываем к отдельное очень быстрое на вставку хранилище. Затем отдельным процессом обновляем лайки и репосты.
В итоге, держим большую нагрузку с минимальными издержками. И с некоторой точностью показываем кол-во лайков и репостов.
это избыточно. надо обеспечить синхронность настроек сеттера поколений и консьюмеров, ориентирующихся на поколения. плюс мониторинг зависших сообщений в кафке.
различные curcuit breaker, throttling, rate limiter, custom idp, token validators, и прочее, что так или иначе регулярно требуется при выставлении публичного api
факторинг для юриков. здесь покупатель физик.
ну и риски считают по разному, в факторинге смотрят на обороты юрика. здесь на физика смотрят как на ... (хз как смотрят, наверно как на физика-заемщика, но беззалоговые кредиты дорогие, на комиссии в 50$ с каждой покупки в 1000$ не проживешь имхо).
Вам надо всего лишь поработать на уже долго живущем проекте, и некоторое время фиксить на нем баги и пилить новые фичи. Где сменились поколения разрабов.
Когда из-за неудачного нейминга, вы полдня ковыряли код, чтобы понять его логику...
После этого полезность правильного нейминга перестанет быть неочевидной.
И про сопроводительный текст для коммитов тоже самое.
Не томите, расскажите уже, чем отличаются менеджмент и руководство.
Увы, бережливое производство не про склады и производство по запросу.
Бережливое производство про процесс непрерывного улучшения. Улучшения чего угодно, что влияет на результат производства. Если долго и целенаправленно улучшать, это дает результат. И это называется "увеличивает производительность", т.е. в единицу времени создается больше полезного.
Точно также как agile не про дейлики и спринты. А про взаимодействие бизнеса и команды, команды между собой, и опять же про процесс непрерывного улучшения. С целью "увеличения производительности".
И как и любая другая деятельность, это (внедрение бережливого производства, например) может быть успешно проведено. А может быть проведено для галочки, или даже во вред.