Хорошая статья. Мне кажется здесь проблема не только в angular, сложность системы диктуется бизнесом. До react/angular фронты пилили не поддерживаемые костыли.
Здесь 2 подхода как на бэке - пишем на фреймворке (spring java), либо на библиотеках для опытных (ФП scala).
Здесь есть проблема с определением стабильных границ между микросервисами - без них сложно получить профит с независимым деплоем частей и не свалиться в распределённый монолит. Если следовать Сэму Ньюману, то нужно начинать с монолитов и по мере стабилизации домена решить, какая конкретно часть в нем применения архитектуры микросервисов. Например увелечение производительности определенного слля или ускорение введения изменений в определенную часть.
Пардон за поток сознания - что-то и хочу в этом роде - смешать базу и Kafka и получить все из "коробки": расширить возможности ACID-транзакций базы транзакциями Kafka (как-то заюзать https://habr.com/ru/company/badoo/blog/333046/).
В своих проектах тоже использовал ключи идемпотентности, но всегда хотелось как-то более бесшовно интегрировать Kafka в бизнес-процессы. Например, можно было "забить" на poller + таблицу очередь и сразу отправлять события, если использовать гарантии доставки exactly once - в этом случае события, кот. отправляет продюсер маркируются транзакцией Kafka и будут доступны всем коньюмерам уже после фиксации офсетов консьюмеров. А если добавить офсеты в базу, то ключи идемпотентности вообще не нужны чисто теоретически.
Имел ввиду, что организация распределенных транзакций через Кафка имеет много болерплейта и сложностей (вы их разобрали)
Хочется что-то вроде гарантии exactly ones для событий + единая транзакция для бизнес моделей в БД. Наткнулся на интересную статью, которая решает ряд проблем за счёт хранения offsets-ов Kafka вне брокера прям в БД
Еще есть интересный вариант - хранить offset-ы Kafka в БД, который позволяет не делать poller. Но наверное имеет проблемы с масштабированием, т.к. вы замыкаетесь на одну БД.
Хорошая статья. Мне кажется здесь проблема не только в angular, сложность системы диктуется бизнесом. До react/angular фронты пилили не поддерживаемые костыли.
Здесь 2 подхода как на бэке - пишем на фреймворке (spring java), либо на библиотеках для опытных (ФП scala).
Тогда ждём и будем переезжать ✌️
Немного оффтоп. Интересно, а проект Loom будет встраиваться в новые jdk
Здесь есть проблема с определением стабильных границ между микросервисами - без них сложно получить профит с независимым деплоем частей и не свалиться в распределённый монолит. Если следовать Сэму Ньюману, то нужно начинать с монолитов и по мере стабилизации домена решить, какая конкретно часть в нем применения архитектуры микросервисов. Например увелечение производительности определенного слля или ускорение введения изменений в определенную часть.
Пардон за поток сознания - что-то и хочу в этом роде - смешать базу и Kafka и получить все из "коробки": расширить возможности ACID-транзакций базы транзакциями Kafka (как-то заюзать https://habr.com/ru/company/badoo/blog/333046/).
В своих проектах тоже использовал ключи идемпотентности, но всегда хотелось как-то более бесшовно интегрировать Kafka в бизнес-процессы. Например, можно было "забить" на poller + таблицу очередь и сразу отправлять события, если использовать гарантии доставки exactly once - в этом случае события, кот. отправляет продюсер маркируются транзакцией Kafka и будут доступны всем коньюмерам уже после фиксации офсетов консьюмеров. А если добавить офсеты в базу, то ключи идемпотентности вообще не нужны чисто теоретически.
Имел ввиду, что организация распределенных транзакций через Кафка имеет много болерплейта и сложностей (вы их разобрали)
Хочется что-то вроде гарантии exactly ones для событий + единая транзакция для бизнес моделей в БД. Наткнулся на интересную статью, которая решает ряд проблем за счёт хранения offsets-ов Kafka вне брокера прям в БД
https://medium.com/p/91042e81c095
Еще есть интересный вариант - хранить offset-ы Kafka в БД, который позволяет не делать poller. Но наверное имеет проблемы с масштабированием, т.к. вы замыкаетесь на одну БД.
Скажите, даунтаймы при ребалансировке насколько критичны - в Kafka с этим есть проблемы
Смелая работа, думал в банках все по старинке - через оракл и хранимки делается) Молодцы
С точки зрения ООП или ФП оформлено слабовато, но главное идея автоматизации