Timur, мне сложно поддержать разговор, я не знаком с твоим продуктом.

Повторю, что не было задачи принести людям свет.
Была задача заиметь инструмент формальной валидации типов на стыке приложения и базы.

Что из него можно построить и как это найдет отклик в прекрасном мире программирования будущего, сказать не берусь :)

Пока удалось построить статический анализатор и зачатки data lineage инструментов.
Т.е, например, можно искать проблемы в уже сгенерированных при помощи ORM запросах. А хотим мы этого или нет, таких проектов абсолютное большинство.

Я даже не сильно расстроюсь, если разработчикам приложений это все не особо пригодится, т.к. есть еще отдельный мир дата инженеринга и там творится мрак и ужас ) Но денег там очень много :)

Как правильно в микросервисах гарантировать получение события определенным сервисом?
Использую moleculer.js и выяснил, что он теряет события, когда сервис перезапускается

Допустим, есть сервис A - он эмитит событие E1
Сервисы B и C слушают это событие, и должны на каждое из них отреагировать. Но получается так, что сервис В может падать и в момент, пока он перезапускается событие Е1 видимо эмитится в старый экземпляр, который никто не получается, и при запуске нового приходит только каждое второе до тех пор, пока moleculer.js не поймет, что предыдущий экземпляр не отвечает

Решением могло бы быть использовать call с retries вместо событий, но дело в том, что сервис А не должен знать про другие сервисы

Сражаться с разработчиками долго, дорого и моей жизни на это точно не хватит. Если ты делаешь что-то, что можно встроить в существующий flow за 10 минут, то это может взлететь. Если для внедрения надо все нафиг переписать, то пардон, но это никто не купит

А покупать не нужно, я делаю новую религию, старый мир в топку вместе с капитализмом )))

"покупать". в переносном смысле

есть процессы, есть инструменты. с ними все ок и ценность для бизнеса лежит не в этой плоскости

Для этого используют саги. https://microservices.io/patterns/data/saga.html

Я не говорю, что вы сделали плохой инструмент, я думаю, что его очень интересно было писать, потому, что он технически и научно сложный. Но вот воспользуются им люди которые хотят решить не существующую проблему плохим образом, этих людей с их ORM-ками нужно вешать, потому, что на них пуль не напасешься

Они и ORM берут потому, что ни SQL ни ООП не осилили и хотя, чтобы им все магия делала

о, классная фраза )

не уверен что это мой кейс, так как сам сервис А не нуждается в ответе об успешной операции от других сервисов, то есть транзакций нет. Самим сервисами В и С важно, чтобы они не пропустили ни одного события, и сервис А ничего не знает о них

Я не супер великий специалист: знаю как по серьёзному гарантируют транзакции в системах на микросервисах и всё. Видимо, в вашем случае, нужен некий упрощённый вариант со сторонним брокером и валидатором транзакций.

Я не воспринял, что был разговор о качестве инструмента, все ок )

90% пишут на ORM.
Жизнь такова, какова она есть, и больше – никакова :)

Кто при этом страдает? DBA. Можем упростить им жизнь? Можем. Давайте дадим им инструмент автоматического поиска проблем, которые уже приплыли в прод. Желательно, чтоб инструмент еще и разрабов, которые ни SQL ни ООП не осилили, бил током. Автоматически.
Вот именно этот инструмент я и стал делать, после того, как стало понятно, что SQL никто не пишет )

Т.е. parsers.dev - это просто кусок holistic.dev, вытащенный наружу. Пригодится кому-то? Ок. Нет - ну и нет. Оно все равно часть другого проекта, который в конечном счете решает другие проблемы.
Как может пригодиться? Вот список идей, выбирайте.

На самом деле самое ценное лежит далеко за пределами парсеров. Это data governance, data linage и data quality.
Поэтому я пошел к дата инженерам. У них там все хуже на несколько порядков. Там и буду жить )

Не стоит полагаться на moleculer в критично важных системах. Если нельзя терять сообщения нужны более надёжные каналы доставки на уровне инфраструктуры (service mesh) или инструментов (message brokers, event streaming)

то есть лучше просто взять ту же Kafka?

kafka это event streaming. оно не всегда хорошо ложится. иногда лучше message brokers

ORM-щиков уже не спасти, но ничего страшного, бабы еще нарожают, а я обучу их DDD.

Я спасаю не ORMшиков, а DBA, которые за ними разгребают ) ORM-щиков уже не спасти, факт

кстати, если все-таки кафка, то рекомендую взглянуть на https://vectorized.io/redpanda/
протокол тот же, только на плюсах и быстрее