T-Planet_If_else_Ermakov
README
КОНТАКТЫ
Телеграм: @egor4yt
Запуск проекта (Docker)
-
Открыть командную строку в директории проекта
-
Настроить окружение
-
Запустить docker-compose
docker-compose up -d -
Приложение доустпно по адресу http://localhost:5173/swagger или http://127.0.0.1:5173/swagger, разницы нет, фронтенд по адресу http://localhost:5553/.
Окружение
Если нужно править какие-то настройки приложения или базы данных, это можно сделать с помощью переменных окружения.
Переменные окружения, с помощью которых настраиваются API и база данных хранятся в файле .env, находящийся в корневой директории проекта
| Переменная | Стандартное значение | Описание |
|---|---|---|
| WEBAPI_PUBLIC_PORT | 5173 | Порт, на котором будет работать API |
| DB_PUBLIC_PORT | 5715 | Порт, на котором будет работать сервис с базой данных PostgreSQL |
| DB_NAME | weather-history | Название базы данных |
| DB_USER | sber | Имя пользователя базы данных |
| DB_PASSWORD | best | Пароль для доступа к базе данных |
| UI_PUBLIC_PORT | 5553 | Порт, на котором запустится Frontend. Менять вместе с REACT_APP_API_URL |
| REACT_APP_API_URL | REACT_APP_API_URL=http://localhost:5553 | URL для которого бекенд разрешит CORS. Менять вместе с UI_PUBLIC_PORT |
Возможно вызовет трудности при проверке проекта
Так как в ТЗ не указано жестких требований к работе с типом date-time, все поля такого типа принимаются в формате ISO-8061 с любым часовым поясом и преобразуются в UTC+00:00, а вовзращаются в формате ISO-8061 с часовым поясом UTC+00:00
UPD: ФИНАЛ:
Иногда интерфейс тупит, не успел сделать норм реализацию. Например: удаление типа региона отрабатывает успешно, но тип не пропадает на UI, чтобы пофиксить - перезагрузите страницу вручную
При удалении аккаунта - вылетает, даже если удалил не тот аккаунт, которым авторизован
Постман коллекция версии 2.1, фронтенд в ней не описал, так как для загрузки страницы требуется Javascript, а постман этого не поддерживает. Умоляю простить, тестить руками в интерфейсе. Добавил только один запрос для UI, чтоб было видно, что проблему не выдумал
Архитектура проекта
Проект WeatherHistory имеет многослойную архитектуру, разделенную на несколько проектов с целью обеспечения чистого кода, гибкости, масштабируемости и удобства поддержки:
1. WeatherHistory.Shared
Этот проект предоставляет общие утилиты и расширения (helper и extension классы), которые используются между различными частями приложения. Эта библиотека классов обеспечивает повторное использование кода и уменьшает связанность между компонентами проекта.
2. WeatherHistory.Data
Содержит всё, что связано с хранением и манипуляцией данными. Проект определяет
3. WeatherHistory.Api.CommandsQueries
Этот проект решает задачи, связанные с бизнес-логикой, через механизмы команд и запросов, внедряя CQRS паттерн, который позволяет разделить операции чтения и записи для повышения производительности и масштабируемости. Используя MediatR, упрощается декомпозиция бизнес-логики на обрабатываемые хэндлерами команды и запросы, что ведет к лучшей организации кода и упрощает поддержку и тестирование. Библиотека AutoMapper помогает в автоматизации преобразования между сущностями базы данных и DTOs, тем самым сокращая объем шаблонного кода.
4. WeatherHistory.Api
Основное приложение веб-API, которое выступает в качестве точки входа в приложение. Запускает миграции для актуализации схемы БД при старте, конфигурирует зависимости для Dependency Injection, настраивает контроллеры, мидлвары и систему авторизации. Использование библиотеки MediatR в этом слое позволяет создать четкое разделение между веб-слоем и слоем приложения, где бизнес-логика может организована в виде команд и запросов, улучшая таким образом читаемость и поддерживаемость кода.
Используя такой подход и структуру проекта, можно достичь высокого уровня абстракции, чистоты кода и легкости в внесении изменений или добавления новых функциональностей.
Результат работы
В проекте были реализованы все требуемые по ТЗ функции.