Для запуска сервиса достаточно выполнить команду make up, файл с необходимыми зависимостями уже заполнен(.env.example).
Для запуска unit тестов c покрытием необходимо выполнить команду make unit-tests.
Для запуска интеграционных тестов для необходимых сценариев, запустите сервис и выполните команду make tests
- реализован сервис со всеми необходимыми ручками и функционалом.
- unit тесты покрывают более 40% бизнес сценариев(70+%).
- реализованы интеграционные тесты на необходимые сценарии и дополнительные.
- описана конфигурация линтера(golangci).
- изменил docker-compose, убрал чувствительные данные в .env(для тестового запуска оставляю .env.example), а остальные положил в config.yaml.
- всего одна ручка для авторизации. По условию задания если нет пользователя, то он создается автоматическм, при этом у нас все еще должна быть проверка паролей. Больше похоже на искусственное усложнение, ведь если пользователь ошибается с именем, то случайно создает нового. Плюс к этому могут возникнуть дополнительные сложности общением с бд.
- таблицу с мерчом и его стоимостью хотел хранить в коде, так как количество мы его не отслеживаем, ассортимент у нас небольшой, да и лишнюю нагрузку с бд это уберет. В итоге все же залил в бд, будет легче масштабироваться и вносить правки в информацию о продукте.
- создание нового пользователя и баланса для него, сначала поместил в транзакцию(чтобы не возникало ситуаций, когда пользователь создан, а баланс для него нет), но позже перенес все это в функцию postgres. Посчитал, что создание пользователя будет не такой уж частой операцией, а что бы самим ручками не ходить в бд дважды, создал функцию(так выглядит надежней). К тому же если мы не создадим для пользователя счет, то при дальнейшем взаимодействии с сервисом это никак не повлияет на других пользователях и не создаст хаос среди информации в бд(все ручки, с возможность изменить информацию в бд, взаимодействуют с балансом, поэтому все операции будут у такого пользователя уходить в ошибку).
- с переводами между пользователями совсем другая ситуация, при наличии баланса и пользователя, мы должны гарантировать корректное выполнение операции. Думаю в данной ситуации будет выгоднее воспользоваться транзакциями.
- при нагрузочном тестировании было выяснено, что большую часть задержки ответа от сервиса по маршуруту
/api/auth(80+%) вызывает именно хеширование пароля и его проверка на соответствие. Ускорить это можно путем снижения безопасности.