Comments 4
Эм. Очереди через реляционную бд это действительно не лучшая идея, но то точно не тупая. Я знаю несколько средне нагруженных сервисов, которые построены на очередях в Oracle и один - очень высоко нагруженный сервис (тысячи записей/чтений в секунду в очередь в базу в пике) Postgre ес что.
Конкретно для задачи которую вы решаете, очередь в базе кажется норм решением для MVP, чтобы не плодить бОльшее количество технологий и инструментов внутри проекта.
А действительно проблемой выглядит - рефактор и улучшение продукта, которого ещё нет.
Да, проблема, что из-за какого-то внутреннего перфекционизма мне хочется сразу сделать хорошо, из-за чего ходил кругами, хотя продуктового опыта нету.)
Про очередь через бд, это оказалось проблемой из-за двух факторов для мен, первая - это дополнительная нагрузка на бэк, хоть и не большая, но тоже существующая, потому как в асинхроне слушать апи, и писать в базу, чтобы потом один раз из нее прочитать, нет особой необходимости.) Второе - это какая-то гарантия доставки, если бэк был перегружен, он по таймауту мог отвалиться и все, беда.) Третье - т.к. я пишу на ноуте, мне необходимо было бэк поставить куда-то, где есть достаточно ресурсов, и я поставил его дома, и нужна была связь, поэтому в дальнейшем я начал использовать Кафку, в которую писал задачи, и из которых читаю результат, просто оказалось удобнее.)
Спасибо за свои размышления про процесс создания сервисов.
Очередь не важно где и как реализовать, но, учитывая, что вы используете докер композ, как я понял, то быстро и просто докер контейнер RabbitMQ описать в конфиге (как пример) и его использовать для очередей. Это позволит вам не распыляться на собственную реализацию системы обмена сообщений и сконцентрироваться на сервисах.
И сперва я, когда поглядел на схему, то ввело в заблуждение Controller — я думал, что это то, что работает с транспортным уровнем, но, как понимаю, это у вас отдельный сервис, и так вы его назвали. Вот это и пример, что одна из основных проблем в программировании — это правильный нейминг. )
А так пожелаю вам продолжать делать и переделывать с изучением подобных сервисов и чтением литературы. Я убежден, что только через практику придет понимание.
Вам сперва необходимо сделать работающий прототип, и неважно будет там г.код или в 1 файле как мешанина. Потом, после, когда у вас заработает и вы ясно увидите, что и где надо поменять и улучшить.
В идеале периодически каждый месяц (достаточно выйти из контекста проекта) поглядывать на свое «творение» и пробовать понять, что там происходит и понятно ли вам, что вы написали в коде.
Спасибо!) Да, про очередь я так же думал взять кролика, но остановился на Кафке, потому как очередность, сама по себе не сильно важна, важно больше доставить сообщение.)
Про нейминг, да, с этим нужно поработать, в данный момент этот промежуточный сервис я называю мидлварей (под таким названием он лежит в гите).) А контроллером изначально называл из-за знакомого паттерна MVC.) А так да, верно, это 3 отдельных сервиса.)
Мое автопротоколирование, начало создания полноценного сервиса