Спасибо, что описал примерные решения проблем выше.
Можно чуть больше узнать о вашей системе?
У вас микросервисы использующие protobuf? Или это какой-то монолит?
Насколько часто сменился протокол за последний год?
Есть ли у вас контроль над всеми клиентами?
Что скажешь про protostuff, доводилось использовать?
Сложно сказать насколько больше могу говорить :) С одной стороны микросервисы, с другой их не 200 и есть возможность иметь для всех один релизный график. Новые поля в протокол могут доезжать каждый спринт. Пока контроль над всеми клиентами есть, может поменяться. Обратная совместимость все равно важна из-за деплоев разных версий и т к некоторые данные в хранилищах тоже лежат в протобафе. protostuff пользоваться не доводилось. Спасибо за находку, в юзкейсах не вижу мобилки, мне может пригодиться. Под мобилки есть protobuf-lite который тоньше обычного протобафа (в lite версии нет рефлексии). Один из плюсов всплывавших flat buffers - это хедер онли либа, она очень тонкая, но вот пока обросла не всеми фичами и по популярности сильно уступает протобафу. Из замеченного это отсутствие удобной отладочной принтилки буферов и конвертации из/в JSON, вялая активность в репе (т е делаю вывод что сам гугл не особо смотрит на fbs), достаточно небрежный подход к ошибкам flatc, которые вылетают юзеру. Чинил там сегфолт, пофиксил его выдачей ошибки и мейнтейнеру было пофиг что сообщение не говорит юзеру что же именно пошло не так. Спрашивал как лучше протестить это и тоже без ответа остался. Приняли фикс сегфолта на ошибку и все. Может быть мне стоило быть настойчивее :) Что-то могло поменяться, плотно смотрел это все зимой. Также при создании сообщения достаточно неудобно собирать вложенные структуры. У протобафа с этим сильно проще. Но это плата за zero copy. Возможно либами это подтянется (или уже подтянулось). Кстати fbs можно конвертировать из протобафа (как схемы так и сообщения). Можно по fbs схеме получать json схему. Есть еще один zero-copy протокол - CapNProto. Его использовать не приходилось, но хотел бы потыкать.
По поводу видоса. Сложилось мнение что их проблема была не в протобафе, а в организационных процессах. Могли они также сделать основную протобаф версию и экстеншены в протокол? Выглядит так что могли. Просто люди лучше знают и понимают JSON, поэтому смогли придумать для него решение которое им подошло. Может быть у них были еще какие-то внутренние причины которые не прослеживаются на докладе. Новые поля можно добавлять не требуя пересборки всех клиентов. Но и эту пересборку можно достаточно удобно организовать. Например, используя такого монстра как bazel (про это могу отдельно поделиться если интересно). Сразу видно у кого какие зависимости по коду, и какой сервис какие proto сущности использует. Если еще вопросы есть буду рад поделиться чем могу :)