Task Tracker

JSON API для таск-трекера: задачи с датой, статусом и тегами; одноразовые и повторяющиеся события; Bearer-авторизация. Спецификация API — docs/openapi.yaml.

Запуск

1. Заполните .env и .postgres.env (можно скопировать из .env.example и .postgres.env.example; для прода пароли лучше сменить).

2. Поднимите контейнеры:

   docker compose up -d

3. Создайте пользователя и получите токен:

   docker compose exec app ./bin/rails c

   User.create!(email: "[email protected]", name: "Test")
   User.last.auth_token

   В development после bin/rails db:seed также доступны [email protected] и токен dev-token.

4. API: http://localhost:3000

5. Импортируйте docs/openapi.yaml в Postman и укажите Bearer-токен в Authorization.

6. Готово — можно тестировать.

Тесты

В проекте используется RSpec.

Запустить PostgreSQL:

docker compose -f compose.dev.yml up -d

Создать базу данных:

bundle exec rails db:create db:migrate

Прогнать тесты:

bundle exec rspec

Дизайнерские решения

• Самое важное - события серии повторяющихся событий адрессуются двумя айдишниками: id серии и номером события в серии.
  • Поэтому, например, чтобы получить данные о конкретном событии серии надо делать запрос:

    GET /tasks/777?repetition_event_number=123
    

• Сделать статусы табличкой, а не условным enum-ом мне захотелось, потому что это даёт возможность в дальнейшем добавить поддержку пользовательских статусов
  • При этом мне нравится идея для внешнего потребителя API создавать иллюзию, что это enum. Мне кажется, так оно значительно проще для восприятия человеком.
• Названия статусов в базе данных пишутся нижним кейсом и по-английски, потому что наверняка у нас будет или на фронте или где-то ещё трансляция этого дела в человеко-читаемые надписи. В том числе, это важно для поддержки разных языков.
  • Но при этом, пользовательские статусы могут создаваться любые, и будут просто проходить мимо этой трансляции.
• Конечно, криво, что обязательные теги в базе имеют русские названия, а всё остальное - английские. Но я просто сделаю вид, что это глупое бизнес-решение, с которым надо смириться. Конечно, я бы лучше по-английски их назвал, а потом прогонял через I18n или аналог, если это надо.
• API для тэгов, наверное, можно было задизайнить по-другому, но сделать классический круд мне показалось значительно проще. Ну и можно потом переделать, если будет необходимость.
• И я решил, что было бы удобно добавлять кастомные теги прямо через поле tags у задачи. Поэтому, если там передаются неизвестные теги, то они тут же создаются в базе.
• Для продакшена я бы обрезал эту фичу с парсингом разных форматов времени. Если мы используем эту штуку для предоставления API, то оптимальнее было бы всё перевести на UNIX таймстемпы. Это бы упростило очень много вещей (например, не надо было бы думать про таймзоны).
  • Но тут я взял то, что мне предложила нейронка, особо не вникая, потому что это удобно для тестирования (через условный постман) реально важного функционала. Не надо, как дурачок, переводить туда-сюда эти неудобные таймстемпы.
• авторизацию сделал просто по токену. Потому что наверняка у нас уже есть реализованная ранее авторизация. Ну и для тестовых целей хватит.
  • ну и добавлять пользователей надо через консоль. Но мне кажется, тут тоже не страшно.
• Удаление я решил сделать мягким: будем менять статус задачи на удалённый. И не возвращать удалённые задачи в API
  • дефолтный скоуп реализован очень плохо. Но не было времени разбираться.

Фундаментальные проблемы решения

• Мне не приходит в голову нормальный алгоритм по поиску N-го чётного/нечётного числа месяца. Поэтому время ответа на запрос для очень отдалённого будущего может занимать очень много времени.
  • Но если пользователю не хочется смотреть, что там будет в 2149762-м году, то всё ок.
  • К тому же, можно ограничить дату конца промежутка и так закрыть косяк.