Юрий Белк – Full stack Developer (страница 26)

– created_at

Почему это важно даже “опционально”:

– нужно заранее решить: файл лежит у нас или мы выдаём ссылку?

– нужно заранее решить: кто может скачать файл?

– нужно заранее решить: как удалять/истекать ссылки?

6.3.5. Уведомления (email/webhook)

Уведомления почти всегда начинаются с двух событий:

– “задача назначена на меня”

– “в задаче новый комментарий”

Каналы:

– email (человеку)

– webhook (внешней системе: Slack/Teams/что угодно)

Мы будем думать об уведомлениях как о событии:

– событие возникло (task_assigned/comment_added)

– его нужно доставить подписчикам

– доставка может быть не мгновенной

– доставка может повторяться при ошибках

Даже если мы не делаем брокер сообщений в первой версии, мы можем заложить модель и API “подписки на webhooks”.

6.4. Границы доступа и типовые сценарии

Чтобы не сделать “дырявую” систему, полезно проговорить простые правила:

1) Пользователь видит только те workspace, где он участник.

2) Пользователь видит только проекты внутри доступных workspace.

3) Задачи доступны только через доступ к workspace/проекту.

4) Метки – внутри workspace, не глобальные.

5) Комментарии видны только тем, кто видит задачу.

Если вы соблюдаете эти пять пунктов, вероятность “случайно отдать данные другой команды” резко падает.

6.5. Что можно установить для комфортной работы (независимо от языка)

Чтобы не страдать с окружением:

– Docker Desktop или альтернативы (для БД/Redis локально)

– PostgreSQL (обычно удобнее как основная БД)

– DBeaver (просмотр БД)

– HTTP-клиент: Postman / Insomnia / или curl (curl – как хлеб: простой, но питательный)

– Markdown редактор (чтобы вести заметки по контрактам)

6.6. Мини-итог главы

Мы зафиксировали домен и сущности, а главное – общий смысл продукта. Дальше нам нужно договориться, как система должна себя вести под нагрузкой, как мы защищаемся от повторов и ошибок, как ведём аудит.

Глава 7. Нефункциональные требования

Нефункциональные требования – это то, из-за чего продукт либо выглядит профессионально, либо выглядит как “оно работало у меня на ноутбуке”.

В TaskFlow мы добавим набор требований, которые встречаются почти везде:

– rate limiting,

– идемпотентность (как паттерн для POST и “платёжных” операций),

– audit log,

– пагинация (cursor vs offset),

– SLA и наблюдаемость (observability).

Это всё звучит серьёзно, но в реальности это просто набор договорённостей и инструментов.

7.1. Rate limiting (ограничение частоты запросов)

Зачем нужно

Если вы открываете регистрацию и логин в интернет, то к вам придут:

– боты,

– перебор паролей,

– странные сканеры,

– и пользователи, которые “обновляют страницу каждые 200 мс”, потому что им тревожно.

Rate limiting решает две задачи:

1) Защищает инфраструктуру (CPU/DB/сеть).

2) Защищает пользователей (брутфорс на логин/пароль).

Что именно лимитируем

Минимум для TaskFlow:

– /auth/register – лимит на IP и/или на email

– /auth/login – лимит на IP и на аккаунт (email)

– “тяжёлые” списки (поиск задач) – лимит на пользователя

Как выражаем лимит

Удобно мыслить в терминах:

– N запросов за T секунд (например, 10 запросов/мин)

– отдельные лимиты для разных endpoint’ов

Пример политики (условно):

– регистрация: 5/час на IP