Сабж. Суть - нигде нет нормального примера, как и в большинстве питонодоков. Разбор что и как все время идет на неком сферическом хелловорлде в вакууме, который запускается через if __name__ == "__main__" и живет 5 секунд. И по итогу нифига не понятно как, например, корректно использовать клиент во взаимодействии между серверами.
Пример: есть 3 сервиса (А, Б, В). Для простоты пусть А - гейт, а Б и В содержат бизнес-логику. У каждого сервиса есть несколько нод. Ноды внезапно могут упасть, затупить, пойти в отказ и т.д. Как правильно написать скажем ручку для фласка на А чтоб она ходила в Б и В?
Что значит «правильно»:
- например дока говорит «канал нужно переиспользовать как можно дольше»; можно ли его скажем держать в статической переменной, или threadlocal, или когда вообще его нужно закрывать; также канал - это p2p или разные субканалы могут подключаться к разным конечным нодам (в случае если одна например приляжет)?
- какие у канала есть опции и как их предполагается использовать? это про тот жирный жсон в котором например идет
grpc.service_config. Предполагается ли что разработчик сервиса А должен знать что там происходит в Б или все-таки разработчик сервиса Б это должен как-то донести, например опциями? - как корректно сделать retry?
- как правильно передать кастомную ошибку и какой код при этом юзать?
- как правильно передавать хедеры и например отслеживать время исполнения запроса, особенно для stream-stream? как вообще предполагается делать distributed tracing?
- как черт возьми корректно распространять протобуфную спеку?
Кто-нибудь знает где есть хоть какая-то адекватная документация по всем параметрам, практикам и прочему? желательно с примерами. А то тот же methodConfig и как его готовить приходится кусками собирать по исходникам и разным сайтам типа SO, при том часто оказывается что то что есть в доке, в спеке и в жизни - сильно разные вещи. Например тот же hedged call в доке есть, и даже структура под него есть, а реализации этого добра нема.
p.s. если что все написанное у меня реализовано, вопрос не в том «как сделать», а в том «как сделать правильно».
