av
d33f37249c
- роадмап отвечает «что умеет и чего не умеет»: PLAN.md → ROADMAP.md, четыре канонические секции, достигнутые звенья строками в «Готово», цели переформулированы возможностями приложения - задачи: род работы и «Затрагивает» набору спринта, 34 заголовка в форму действия, «Завершение» целей перечнями со ссылкой из каждой задачи - вычитка проходами task-form и doc-wording, починены протухшие факты в README, паспорте и review.md
23 lines
1.9 KiB
Markdown
23 lines
1.9 KiB
Markdown
# [idea] NDJSON-поток для больших выборок Read API
|
|
|
|
- **Секция:** Ядро
|
|
- **Зачем:** Выборка нижнего слоя за месяц не влезает в один JSON-ответ — либо поток, либо пагинация
|
|
- **Теги:** goal:read-api
|
|
|
|
Read API отдаёт ответ одним JSON. Для выборок нижнего слоя за длинный период
|
|
это не работает: `heart_rate` в слое `raw` — порядка сотни тысяч координат в
|
|
сутки, и месяц такого ряда не влезет ни в память клиента, ни в разумный ответ.
|
|
|
|
Сейчас проблема закрыта с другой стороны — правилом размера ответа: сервер сам
|
|
берёт сетку погрубее, когда разбивка не задана, и отвечает ошибкой со списком
|
|
доступных сеток, когда задана явно. Это защищает агента с ограниченным
|
|
контекстом, но не помогает клиенту, которому действительно нужен весь ряд —
|
|
например, разовой выгрузке в другой инструмент.
|
|
|
|
Почему идея, а не задача: неизвестно, появится ли такой клиент. Если появится,
|
|
выбор между NDJSON-потоком и курсорной пагинацией зависит от того, читает он
|
|
последовательно или с возвратами.
|
|
|
|
Связано: `docs/architecture.md` → «Свёртка и размер ответа», задача
|
|
`read-api-response-limit` (правило размера ответа проектируется там).
|