В качестве входного испытания ставится задача написать backend проект, который будет отвечать на запросы по протоколу HTTP. Передача данных должна осуществляться при помощи формата JSON.
Необходимо создать проект позволяющий контролировать покупки человека. В зависимости от уровня он будет содержать в себе различный функционал.
Сегодня в лаборатории для написания Backend сервисов используются следующие технологии:
Backend:
Database:
Cache:
Message broker:
Желательно реализовывать проект с использованием технологий, описанных выше, за счет простоты дальнейшего встраивания в рабочй процесс. Но в рамках тестового задания жестких ограничений на используемый стек нет.
Обязательной является возможность запуска вашего проекта в Docker среде, ввиду того, что сегодня как в лаборатории так и мире эта технология крайне популярна.
Образы приложений необходимо отправить в личный docker hub. Весь сервис(включая окружение в виде БД и прочего) должен быть работоспособен, и подниматься при помощи следующих команд:
docker-compose pull
docker-compose up -dТо, какие маршруты у приложения существуют, какие параметры принимают, что возвращают, какие коды отдают - все это необходимо задокументировать.
Можно создать в репозитории отдельный файл API_DOC.md, и в нем описать все возможные маршруты/форматы данных, или воспользоваться инструментом Swagger и OpenAPI. Второй вариант является приоритетным, он является де-факто стандартом описания HTTP API, и может быть сгенерирован автоматически на основе написанного кода.
Желательным является наличие тестов для вашего сервиса. Речь идет как о Unit тестах, так и о E2E тестах. Для последних в лаборатории применяется инструмент Karate. При отсутствии опыта работы с этой технологией предлагается применять тестирование в Postman. Данные два примера даны для ознакомления, выбор технологии тестирования остается за автором решения.
Не приемлемо хранение данных в памяти приложения. Необходима полноценная отдельная база данных, начиная с SQLite. In-memory хранилища(например Redis) относятся в данном контексте к полноценным базам данных.
Как описано выше - необходимо настроить окружение так, чтобы все дополнительные сервисы запускались в docker-compose. Вам необходимо проработать механизм автоматического применения миграций при старте приложения. Разумеется, если таковые имеются в вашем проекте.
Необходим сервис "Покупки", который может хранить данные о покупках разных людей. О покупке необходимо хранить следующую информацию:
- Дата покупки
- Название товара
- Сумму, потраченную на товар
Необходима базовая концепция аутентификации. Например, можно передавать ID человека, про которого запрашивается/отправляется информация через строку запроса, или заголовок.
На данном уровне подразумевается, что сервис является "записной книжкой", в которую человек может поместить информацию о своих покупках.
На втором уровне появляется как минимум второй сервис "Магазины", который должен быть отдельным приложением (процессом). Он должен управлять информацией о доступных магазинах, о товарах в них, стоимости количестве и тд.
-
Покупки
- Необходимо добавить возможность категоризации покупок. Категории могут как подтягиваться из "Магазинов", так и устанавливаться пользователем вручную.
- Пользователь должен иметь возможность указать, при помощи какого способа оплаты была совершена покупка.
- Понятие чека
- Теперь каждая отдельная покупка должна существовать в контексте чека, из конкретного магазина.
-
Магазины
О магазинах необходимо хранить следующую информацию:
- Название
- Адрес
- Телефон
- Список доступных позиций (Название, описание, стоимость ...)
- Количество единиц каждой позиции
Магазин должен обеспечивать возможность что-то в нем купить, при этом важно обратить внимание на безопасность данных, и не дать возможность пользователю API купить больше товара, чем есть в магазине. О каждой покупке магазин должен знать, кто когда что в каком количестве и на какую сумму купил.
Теперь все покупки, доступные пользователю, не задаются им в ручном режиме, а формируются из покупки в конкретном магазине. Необходимо продумать, как правильно построить маршруты, как поднять сервисы, как протестировать функционал, как защищены данные и тд.
Сами сервисы могут быть запущены на разных портах, для удобного доступа к каждому из них.
На финальном уровне добавляется еще один сервис "Заводы". Сущность "Завод" производит какую-либо продукцию в единицу времени, и поставляет её в магазин, без стоимости, пусть он обязан поставлять и точка.
У каждого завода должен быть перечень товаров, которые он производит, и производительность, сколько единиц продуктов он производит за единицу времени. Эти параметры в рамках данного задания могут быть заданы на этапе конфигурации сервиса "Заводы".
Таким образом, на данном уровне должна получиться следующая схема:
- Магазины существуют, товаров в наличии у них нет
- Никто ничего в этих магазинах купить не имеет возможности
- Заводы, в соответствии со своей производительностью производят и поставляют товары в магазины
- Теперь магазины могут продавать товары пользователям
Данная система должна работать корректно в условиях недоступности какого-либо сервиса. Так, завод который не может получить доступ к магазину (упал сервер с сервисом "магазины") не прекращает свою работу, а нарабатывает единицы товара, и при появлении доступа к магазину - отправляет. Пользователь не может купить что-то, если нет доступа к сервису "Покупки", и так далее. Необходимо проработать максимальное количество сценариев.
Сценарии отказа и поведение сервисов не регламентируется заданием, необходимо самостоятельно продумать возможные сценарии и сохранить максимальную работоспособность проекта в сложившемся окружении(неполадки с доступом и тд).
Все сервисы должны быть доступны по одному порту (api gateway, reverse proxy, и тд).