В текущем проекте создан веб-сервер, который реализует функциональность планировщика задач. Планировщик умеет хранить задачи, каждая из них содержит дату дедлайна и заголовок с комментарием. Задачи могут повторяться по заданному правилу: например, ежегодно, через какое-то количество дней, в определённые дни месяца или недели. Если отметить такую задачу как выполненную, она переносится на следующую дату в соответствии с правилом. Обычные задачи при выполнении будут просто удаляться. API содержит следующие операции:
- добавить задачу;
- получить список задач;
- удалить задачу;
- получить параметры задачи;
- изменить параметры задачи;
- отметить задачу как выполненную.
Создан минимальный веб-сервер, который слушает определённый порт и возвращает запрашиваемые файлы фронтенда. Созданный сервер при запуске приложения доступен по адресу http://localhost:7540/ '*' Реализована возможность определять извне порт при запуске сервера. Если в файле .env существует переменная окружения TODO_PORT, сервер при старте должен слушает порт со значением этой переменной. Например, TODO_PORT=8080. Для проверки функционала можно запустить тесты: 'go test -run ^TestApp$ ./tests' Если в переменной окружения указан нестандартный порт, то его также нужно указать в файле tests/settings.go в переменной Port
Спроектирована и и написан алгоритм создания базу данных SQLite. При запуске сервер проверяет, существует ли в текущей директории файл scheduler.db. Если его нет, то создается новая база данных с таблицей scheduler. '*' Реализована возможность определять путь к файлу базы данных через переменную окружения (файл .env) - если указана не пустая строка DBFILE, то она будет использована в качестве пути к базе данных. Например, TODO_DBFILE="./my_db.db". Для проверки функционала можно запустить тесты: 'go test -run ^TestDB$ ./tests' Если в переменной окружения указан нестандартный путь к базе, то его также нужно указать в файле tests/settings.go в переменной TODO_DBFile
Правила повторения задач хранятся в колонке repeat в таблице scheduler созданной БД. Если правило не указано, отмеченная выполненной задача будет удаляться из таблицы. Реализованы следующие правила:
- d <число> — задача переносится на указанное число дней. Максимально допустимое число равно 400. Примеры: d 1 — каждый день; d 7 — для вычисления следующей даты добавляем семь дней; d 60 — переносим на 60 дней.
- y — задача выполняется ежегодно. Этот параметр не требует дополнительных уточнений. При выполнении задачи дата перенесётся на год вперёд.
Добавлен POST-обработчик /api/task, который добавляет задачу в базу данных. Запрос и ответ передаются в JSON-формате. Запрос состоит из следующих строковых полей:
- date — дата задачи в формате 20060102;
- title — заголовок задачи. Обязательное поле;
- comment — комментарий к задаче;
- repeat — правило повторения. Используется такой же формат, как в предыдущем шаге. Для проверки функционала можно запустить тесты: 'go test -run ^TestAddTask$ ./tests'
Реализован обработчик для GET-запроса /api/tasks. Он возвращает список ближайших задач в формате JSON в виде списка в поле tasks. Задачи отсортированы по дате в сторону увеличения. Каждая задача содержит все поля таблицы scheduler в виде строк. Дата представлена в формате 20060102. Если задач нет, возвращается пустой список. При ошибке возвращается JSON-объект с полем error. '*' Добавлена возможность поиска задач. Если в запросе присутствует параметр search, то он будет обработан по следующему правилу: Например, /api/tasks?search=бассейн возвратит задачи со словом «бассейн» в полях title или comment. Если параметр search на соответствует формату 02.01.2006, то будут возвращены задачи на конкретную дату. То есть, по запросу /api/tasks?search=08.02.2024 должны возвратятся задачи на 8 февраля 2024 года. Для проверки функционала можно запустить тесты: 'go test -run ^TestTasks$ ./tests' Так как реализован функционал поиска, то необходимо в tests/settings.go в переменной Search присвоить значение true.
Для формы редактирования задачи реализован обработчик GET-запроса /api/task?id=<идентификатор>. Запрос возвращает JSON-объект со всеми полями задачи. Для сохранения данных добавлен обработчик PUT-запроса в хендлер для /api/task. При этом данные проверятются так же, как при добавлении задачи. В случае успешного изменения должен возвращается пустой JSON {}, а в случае ошибки, она записывается в поле error. Для проверки функционала можно запустить тесты: 'go test -run ^TestEditTask$ ./tests'
Написан обработчик для POST-запроса /api/task/done, который делает задачу выполненной. Для периодической задачи рассчитывется и устанавливается дата следующего выполнения. Одноразовая задача с пустым полем repeat удаляется. Идентификатор задачи передаётся в самом запросе /api/task/done?id=<идентификатор>. В случае успешного удаления возвращается пустой JSON {}, а в случае ошибки, она указана в поле error. Для проверки функционала можно запустить тесты: 'go test -run ^TestDone$ ./tests'
В хендлер /api/task добавлена обработка запроса с методом DELETE — /api/task?id=<идентификатор>. В этом случае из таблицы scheduler задачу с указанным идентификатором. Ответ сервера должен быть аналогичен ответу на запрос /api/task/done - возвращается {} или, в случае ошибки, JSON с полем error. Для проверки функционала можно запустить тесты: 'go test -run ^TestDelTask$ ./tests' Для запуска всех тестов необходимо выполнить команду 'go test ./tests'
'*' Если в файле .env задано значение переменной TODO_PASSWORD, то включается механизм аутентификации. Пользователю будет предложено указать пароль. Если он совпаден со значением, указанным в переменной TODO_PASSWORD, то авторизация будет успешной и сформируется JWT-токен. Токен сохранится в куках фронтэнда на 8 часов и будет использоваться и проверяться в дальнейшейшем при обращении к API сервера:
- /api/task — все поддерживаемые HTTP методы;
- /api/tasks — получение списка задач;
- /api/task/done — запрос на выполнение задачи. Чтобы тесты смогли запускаться, нужно присвоить переменной Token в tests/settings.go значение токена, которое сервер возвратил из '/api/signin' и которое хранится в куке token.
В директории tests находятся тесты для проверки API, которое должно быть реализовано в веб-сервере. Директория web содержит файлы фронтенда. В директории .github\workflows содержатся описания пайплайнов запуска тестов и деполя приложения для механизма Github Actions.
