Обновить

Комментарии 9

Спасибо за статью, позволю себе несколько замечаний по коду (так сказать ревью):

  • Mono<@NonNull Void> - крайне спорно и по-моему бессмысленно

  • в UserService отсутствует обработка ошибок. Вообще.

В целом подозреваю, что все это сделано из-за быстроты и генерации части кода OpenAPI Generator. Советую поставить openApiNullable: "true".

Есть непонятный мне конфликт:
useOptional: "true", //Использовать Optional
openApiNullable: "false", // Но ничего не может быть null?!

В тесте вообще не пойму откуда User user = new User();

Ведь если это DTO из OpenAPI то как минимум в коде вижу UpdateUser. Да и что UpdateUser делает в createUser методе?)

В github вообще не нашел папки по пути ru.maximserver.vmuserservice.model указанные в сервисном слое.

Очень много загадочного в проекте на мой взгляд))

Прошу простить, что надушнил, но кто-то(например я) захочет что-то изучить по вашему коду и столкнется с множеством проблем.

Добрый день! В проекте нет пакета model - верно . Классы пакета генерируются openApiGenerator. Чтобы они появились в папке build нужно запустить сборку проекта.

Поправил тест, сделал фикс, поменял User на UpdateUser. Спасибо за замечание.
https://github.com/maxmiracle/vm-user-service/commit/d27e55ed816cf45f91e33ddac7db5352b23c1f34
Действительно, UpdateUser используется и для post (create) и для update. А User для get. Согласен, что это не очень хорошее допущение для примера.
Эти классы генерируются из OpenApi на лету. По легенде, это придумал Системный Аналитик:)

Я бы вам порекомендовал в качестве дто использовать не объекты из OpenApi, а из JOOQ. Там и record'ы есть для спокойной передачи данных

С точки зрения бизнес логики это было сделано в контексте хранения пользователей авторизовавшихся через vk. vk_id не должен повторятся по требованиям. Эта бизнес логика безотносительнп темы статьи. Прошу меня простить.

Почему выбран реактивный стек? (особенно учитывая вводные данные в виде java 21 в которой уже есть virtual threads) Стильно, модно, молодежно? Тогда еще напишите, если есть конечно опыт, во что он превратится через несколько лет активной разработки разными людьми, когда там будет что то сложнее этого hello world. И как его прекрасно будет дебажить. Статья явно рассчитана на начинающих, может не стоит вот так вот сразу испытывать устойчивость их психики реактивщиной?

Добрый день!

Реактивный движок актуален, когда важно быстро обработать запрос. Из своей практики приведу несколько примеров проектов: в одном случае это был платёжный шлюз, в другом — кредитный конвейер. Конечно, проблемы с отладкой возможны, однако при грамотной организации автотестов это уже не столь критично, поскольку достигается значительное преимущество. Если заказчик внимательно следит за производительностью через JMeter и учитывает каждую миллисекунду, выбор реактивного движка становится вполне обоснованным. По virtual threads надо проводить тесты и смотреть, будет ли это сопоставимо по эффекту. Кстати, отличная тема для изучения и написания статьи!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации