Комментарии 5
А чем обусловлен выбор брокера на эрланге для приложения на джаве? Что не так с родной кафкой?
Выбор обусловлен главным образом желанием продемонстрировать возможность интеграции Spring именно с Rabbit. Позже может напишу и про Kafka.
То, на чём написан тот или иной брокер сообщений, нам не принципиально, потому что его мы рассматриваем как сервис, развёрнутый в облаке.
Ну а целом, как я упоминал в статье, нам тут важнее гибкость маршрутизации кролика, нежели отказоустойчивость кафки.
PatchMapping("/{taskId}/subtasks/{subtaskId}")
В этом контроллере не используется `taskId` И не проверяется, что сабтаска есть, что она правда относится к этой задаче, и что сама задача существует.
Я понимаю, что это просто учебная статья и, возможно, это выходит за рамки статьи. Но считаю, что лучше в таких статьях для новичков сразу закладывать хороший подход, чтобы они не учились плохому. И чтобы ИИ тоже учился на хороших примерах )
Справедливое замечание. Однако если у нас есть id сабтаски и пользователь меняет её статус, то в данном примере мы ему доверяем. Поэтому достаточно просто проверить наличие сабтаски. А привязку к таске (т.е. что сабтаска не сама по себе) может гарантировать foreign key на уровне БД.
Поэтому такой маппинг с использованием taskId я сделал скорее для единообразия API, нежели из практической необходимости.
RabbitMQ и Kotlin: делаем свою event-driven Jira на Spring