Исправление upcFrost, (текущая версия) :
Если кратко - ты предлагаешь из протобуфа сделать по сути сокет с плоской и крайне размытой структурой. Спасибо, но звучит чёт так себе. Человеку, который будет вызывать сервис используя proto-спек должно быть чётко понятно какое уведомление чего требует, и это должно быть понятно без заглядывания в шаблон самого уведомления, иначе ломаются абсолютно все абстракции начиная от зоны ответственности сервиса. Либо нужно сразу писать тонну хелперов которые будут говорить юзеру что какому уведомлению нужно, но тогда сам proto-спек по сути бесполезен без наличия знаний о том что происходит внутри. В том что ты предлагаешь будет адская мешанина, которая не сильно лучше чем просить строку с жсоном внутри и потом гадать что в ней должно быть. Для такого никакой протобуф и так не нужен.
Если по пунктам:
Почему, например, signup 6 штук, а не одно с параметрами?
Потому что форматы сообщений на пуш, смс, письмо, и мессенджеры принципиально разные. Например смс нужен номер и caller ID, пушу нужны свистоперди типа звука уведомления, письму сам понимаешь. Валить все в одно сообщение это помойка. Уведомления о действитиях юзера тоже бывают крайне разные в зависимости от ситуации и желания левой пятки составителя шаблона
Опциональность полей в proto3 просто есть
Есть, но это не повод превращать сообщения в помойку. См выше.
они и только они обеспечивают прямую совместимость при удалении полей и обратную при добавлении
Вообще не относится к теме, да и сама эта псевдо-опциональность - предмет вечных срачей
В некоторых случаях вместо oneof вообще предпочтительнее использовать просто набор опциональных полей.
Явно не в этом. Человек, делающий запрос к сервису, не должен лезть искать как же там выглядит шаблон уведомления и какие он параметры берет. Это все должно быть четко описано сообщением интерфейса
А в протобуфах остаётся чистый транспорт, расширяемый
Чего ж тогда расширялку в proto3 выкинули?
обратно совместимый
WhichOneOf смотрит на тебя с укором.
Исходная версия upcFrost, :
Если кратко - ты предлагаешь из протобуфа сделать по сути сокет с плоской и крайне размытой структурой. Спасибо, но звучит чёт так себе. Человеку, который будет вызывать сервис используя proto-спек должно быть чётко понятно какое уведомление чего требует, и это должно быть понятно без заглядывания в шаблон самого уведомления, иначе ломаются абсолютно все абстракции начиная от зоны ответственности сервиса. В том что ты предлагаешь будет просто адская мешанина, которая не сильно лучше чем просить строку с жсоном внутри и потом гадать что в ней должно быть. Для такого никакой протобуф и так не нужен.
Если по пунктам:
Почему, например, signup 6 штук, а не одно с параметрами?
Потому что форматы сообщений на пуш, смс, письмо, и мессенджеры принципиально разные. Например смс нужен номер и caller ID, пушу нужны свистоперди типа звука уведомления, письму сам понимаешь. Валить все в одно сообщение это помойка. Уведомления о действитиях юзера тоже бывают крайне разные в зависимости от ситуации и желания левой пятки составителя шаблона
Опциональность полей в proto3 просто есть
Есть, но это не повод превращать сообщения в помойку. См выше.
они и только они обеспечивают прямую совместимость при удалении полей и обратную при добавлении
Вообще не относится к теме, да и сама эта псевдо-опциональность - предмет вечных срачей
В некоторых случаях вместо oneof вообще предпочтительнее использовать просто набор опциональных полей.
Явно не в этом. Человек, делающий запрос к сервису, не должен лезть искать как же там выглядит шаблон уведомления и какие он параметры берет. Это все должно быть четко описано сообщением интерфейса
А в протобуфах остаётся чистый транспорт, расширяемый
Чего ж тогда расширялку в proto3 выкинули?
обратно совместимый
WhichOneOf смотрит на тебя с укором.