Closed
Description
And stick on v1.
The list of actions TBD.
NB: Don't forget to write a good explanation why we discard v2.
Supersedes #132.
Details in Russian
Обсудили совместимость между версиями http. Результат такой:
Зачем был нужен http v2, и что получилось:
- Использовать один роутер с разными серверами (встроенный http на Lua/C + nginx). В итоге для nginx (в связи с особенностями нашего nginx upstrem модуля) там предлагается кастомный pre/post-процессинг, что в значительной степени нивелирует идею. Надо было делать определенную часть на стороне nginx-модуля (произвольный формат запроса и ответа).
- Поддержка middleware (например, авторизация). Утверждается, что сделана она в таком виде, что все равно приходится делать замыкания, как и в v1 (Ярик пробовал).
- Было там что-то про умное разрешение коллизий роутов, но деталей я не помню, да и кейс кажется довольно специфичным.
Что еще пошло не так:
- Перф просел на 26% на синтетике (со слоем совместимости для v1 — 39%).
- Сломали обратную совместимость.
Так что, кажется, что мы все согласны признать http v2 неудачным экспериментом. В связи с этим предполагаются примерно такие действия:
- Поддержку v1 в v2, пожалуй, катить нет смысла. Кажется, это особенно никому не упротит жизнь, поскольку подталкивать пользователей к переходу на v2 мы не будем. (BTW, в cartridge пользователи добавляют роуты в инстанс картриджа, так что прибить к инстансу версию api тоже не получится.)
- Мы коммитились, что rpm/deb пакеты не удаляются, поэтому будем увеличивать epoch для http v1.
- С luarocks-сервера удалим рокспеки для v2, но сделаем пакет http-v2.
- Ветки. Сделать ветку v2 (как backup) с состоянием текущего мастера. Либо ревертнуть master до состояния 1.1.0 одним коммитом, либо зафорспушить master в 1.1.0.
Ничего не забыл?
Итого в httpng нам надо будет просто поддержать API v1.
Benchmarks: https://gist.github.com/Totktonada/667b504bdad8cbc5777a0442d1181230
Metadata
Metadata
Assignees
Labels
No labels