В 24 году довелось плотно познакомиться с транспортом через БД, как раз через postgresql. Даже коммитил в репозиторий MT с целью исправить баги :) На мой взгляд, самым главным преимуществом перед стандартным транспортом является возможность организации партиционирования и порядка обработки сообщений. В такой конфигурации работа с сообщениями начинает очень сильно напоминать кафку, только в базе данных. Вот ссылка на твиттер автора MT, где он упоминает мой демонстрационный пример: https://x.com/PhatBoyG/status/1779168191773556797
Поясните, пожалуйста, пару моментов по поводу недостатков distributed кэша:
Все кэшированные данные должны поддерживать сериализацию и десериализацию, что не всегда возможно сделать прозрачно для всех сущностей в приложении;
В последствии, при масштабировании, данные будут передаваться в redis для последующей синхронизации. В этот момент будет происходить сериализация/десериализация, или я не прав? Если так, то «проблема» есть и с in-memory кэшем.
Возможно снижение производительности по сравнению со встроенной кэш-памятью из-за сетевых вызовов для кэшированных данных (network latency)
Опять же, при синхронизации будет происходить общение с redis. Правильно ли я понимаю, что снижения производительности не будет только для пользователя?
Автор, вы уделили слишком мало времени для изучения Swashbuckle. github.com/domaindrivendev/Swashbuckle.AspNetCore
Почитайте. Это очень гибкий инструмент с довольно большим количеством пакетов.
В нашей организации он покрывает все кейсы, когда нужно сгенерировать спецификацию API.
Пишу этот пост для того, чтобы те, кто задумался об автоматической генерации документации, знали о существовании решения, не уступающего по функциональности выбранному вами.
P.S. а ещё Swashbuckle, судя по github, популярнее :)
В 24 году довелось плотно познакомиться с транспортом через БД, как раз через postgresql. Даже коммитил в репозиторий MT с целью исправить баги :)
На мой взгляд, самым главным преимуществом перед стандартным транспортом является возможность организации партиционирования и порядка обработки сообщений. В такой конфигурации работа с сообщениями начинает очень сильно напоминать кафку, только в базе данных.
Вот ссылка на твиттер автора MT, где он упоминает мой демонстрационный пример: https://x.com/PhatBoyG/status/1779168191773556797
Можно, пожалуйста, ссылку на керамические капы?
Akko и FL Esports хорошие компании, слежу за их продуктами.
В последствии, при масштабировании, данные будут передаваться в redis для последующей синхронизации. В этот момент будет происходить сериализация/десериализация, или я не прав? Если так, то «проблема» есть и с in-memory кэшем.
Опять же, при синхронизации будет происходить общение с redis. Правильно ли я понимаю, что снижения производительности не будет только для пользователя?
github.com/domaindrivendev/Swashbuckle.AspNetCore
Почитайте. Это очень гибкий инструмент с довольно большим количеством пакетов.
В нашей организации он покрывает все кейсы, когда нужно сгенерировать спецификацию API.
Пишу этот пост для того, чтобы те, кто задумался об автоматической генерации документации, знали о существовании решения, не уступающего по функциональности выбранному вами.
P.S. а ещё Swashbuckle, судя по github, популярнее :)