Никита Прокопов (tonsky) wrote,
Никита Прокопов
tonsky

Categories:

When in doubt, write a DTD

Хочу поговорить про схемы. Поводов два — во-первых, Cognitect (company behind clojure/core и Datomic) выпустила Transit, протокол сериализации данных, и в нем не предусмотрено out-of-band схемы. Точнее, повод это HackerNews тред, в котором пророчат будущее за протоколами с явной схемой. Во-вторых, мне на глаза попался сборник HTTP API guidelines, и там безапелляционно требуют прикладывать машинно-верифицируемую схему к вашему API (и заметьте, что никак не мотивируют это).

Преимущества иметь схему заранее — быстрый парсинг. Конечно protobuf/thrift парсятся быстрее JSON, как бы ни оптимизировали последний. Подход performance first затуманил взгляд многим тысячам программистов, ведь когда слышишь «зато мы можем кодировать 120Mb/sec», из рассмотрения уходят любые другие факторы. Включая, к сожалению, и вопрос «а наберется ли у нас эти 120 Мб в секунду»?

Все следующие преимущества проходят по разряду спорных или даже маргинальных. Возможность запустить механический валидатор по возвращенному документу это преимущество уровня статической типизации в ЯП — уберегает от самых тривиальных ошибок вроде опечаток (эх, если бы все мои проблемы были такими простыми!), но никогда не поможет отличить смысловые ошибки вроде перепутанных min и max. Плюс, если статическую типизацию хотя бы ясно когда и как запускать, то когда валидировать схему не очень понятно. На каждый пришедший документ? Выборочно? В режиме разработки только? И что делать, когда документ не прошел валидацию? То есть, непонятен банальнейший сценарий использования, последовательность действий. В XML был механизм DTD, например, валялись в документах ссылки на схему, или неработающие, или устаревшие. Чёт не прижилось.

Дальше по нарастающей идут сложности, а не преимущества. Например, как описать вариабельный ответ? Скажем, если в запросе я указываю, какие поля хочу видеть в ответе. Или если ответ это список разнородных ресурсов. Или я хочу выразить «присутствовать должно только одно поле из вот этих трех». Это или усложняет язык описания схемы (и тогда все на нее забьют), или поднимает вопрос «а зачем нам схема, если она даже половину синтаксических ошибок не ловит»?

Есть еще проблема миграции. В какой-то момент по системе будут летать сообщения хорошо если двух, а то и пяти-шести версий (если лень, скажем, 5 Тб базу конвертировать в новый формат). И ладно если это всё внутри, как-то можно с этим справиться (переучиваем сначала приемник, затем передатчик). А внешний клиент, который сидит на схеме X, и вдруг начинает получать сообщения в формате X+1? Да, часть простейших миграций можно предусмотреть, но когда содержимое документа парсится на основании чего-то снаружи, отстающий клиент рано или позжно даже прочитать сообщение не сможет. То есть проблема возникнет не на этапе «я не знаю что мне с этим делать», проблема возникнет еще на этапе чтения бинарного потока, когда никакую логику/эвристику пользовательский код еще не может применить.

Страдает и программист, потому что сообщения для него непрозрачны. Браузер, скажем, может распечатать JSON, а вот protobuf — не может, и нельзя написать универсальную тулзу-просмотрщик protobuf-а. Потому что схему надо как-то доставлять к месту где она нужна, отдельно от сообщения, а это неудобно.

В идеале, конечно, иметь схему хорошо и правильно. Но дальше мысль останавливается. По мне так, когда нет ясного сценария «как я это буду использовать и какую получу выгоду», это вещь бесполезная. Когда-то люди верили, что нужно все аннотировать в машинно-читаемом формате, и компьютеры сами будут находить друг у друга API и разбираться, как разговаривать по ним (WSDL куда-то сюда метил). В принципе, проаннотрировать, получается, можно, а вот сделать такой компьютер, чтобы разобрался, оказалось непросто. В итоге все API прекрасно существуют с документацией в человеко-читаемом формате, а вся семантика проходит через программиста. SkyNet если и зарождается, то очень медленно.

Tags: веб-шмеб, девелопмент, загадка, популярные заблуждения, ходил в народ, я что-то пропустил
Subscribe
  • Post a new comment

    Error

    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 29 comments