[{"data":1,"prerenderedAt":86},["ShallowReactive",2],{"content:\u002F07-rpc-grpc\u002F00-intro":3},{"title":4,"description":5,"path":6,"body":7},"Введение в RPC и gRPC","Этот модуль нужен, чтобы спокойно разобраться с внутренним общением сервисов. REST остаётся хорошим выбором для публичных HTTP API, но внутри распределённой системы часто важнее другое: строгий контракт, сгенерированные клиенты, понятные ошибки, deadlines и предсказуемая эволюция схем.","\u002F07-rpc-grpc\u002F00-intro",{"type":8,"value":9,"toc":80},"minimark",[10,14,17,25,30,37,40,50,54,57,61],[11,12,4],"h1",{"id":13},"введение-в-rpc-и-grpc",[15,16,5],"p",{},[15,18,19,20,24],{},"gRPC не делает сеть простой. Он делает договор между сервисами явным. Вы всё равно будете думать про таймауты, обратную совместимость, ретраи, нагрузку и диагностику, но будете делать это не через набор неформальных JSON-описаний, а через ",[21,22,23],"code",{},".proto","-контракты и единый runtime.",[26,27,29],"h2",{"id":28},"что-будет-внутри","Что будет внутри",[15,31,32,33,36],{},"В модуле разберём, чем RPC отличается от REST, как устроены Protocol Buffers, как писать gRPC server и client на Go, как передавать ",[21,34,35],{},"context",", deadlines и metadata, как маппить ошибки, где место gRPC в Clean Architecture и когда streaming действительно нужен.",[15,38,39],{},"К концу модуля у вас должна сложиться такая схема:",[41,42,48],"pre",{"className":43,"code":45,"language":46,"meta":47},[44],"language-text",".proto contract -> generated Go code -> server\u002Fclient -> deadlines\u002Ferrors\u002Fobservability\n","text","",[21,49,45],{"__ignoreMap":47},[26,51,53],{"id":52},"как-понять-что-освоил","Как понять, что освоил",[15,55,56],{},"Вы освоили модуль, если можете спроектировать небольшой gRPC API, объяснить ограничения protobuf, написать клиент и сервер на Go, корректно обработать отмену запроса и не спрятать транспортные детали внутрь бизнес-логики.",[26,58,60],{"id":59},"рабочие-ориентиры","Рабочие ориентиры",[62,63,64,71,77],"ul",{},[65,66,67,68,70],"li",{},"Контракт должен быть стабильнее реализации. ",[21,69,23],{}," меняется осторожнее, чем Go-код за ним.",[65,72,73,74,76],{},"Deadline без обработки ошибки почти бесполезен. Сервис должен не только принять ",[21,75,35],{},", но и уважать его.",[65,78,79],{},"gRPC хорош для service-to-service, но не обязан заменять REST везде. Выбор транспорта должен вытекать из сценария, а не из моды.",{"title":47,"searchDepth":81,"depth":81,"links":82},2,[83,84,85],{"id":28,"depth":81,"text":29},{"id":52,"depth":81,"text":53},{"id":59,"depth":81,"text":60},1781022064679]