Cooking gRPC

Cooking gRPC

4618c5e97c59abd315cc2d7dc809f8c8?s=128

Alexey Palazhchenko

January 11, 2018
Tweet

Transcript

  1. Parental advisory Borken English

  2. None
  3. None
  4. None
  5. Cooking gRPC

  6. Who knows what is gRPC?

  7. What «g» in «gRPC» stands for?

  8. 1.google What «g» in «gRPC» stands for?

  9. 1.google 2.good What «g» in «gRPC» stands for?

  10. 1.google 2.good 3.generous What «g» in «gRPC» stands for?

  11. 1.google 2.good 3.generous 4.gRPC What «g» in «gRPC» stands for?

  12. 1.google 2.good 3.generous 4.gRPC What «g» in «gRPC» stands for?

  13. https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md Each version of gRPC gets a new description of

    what the 'g' stands for, since we've never really been able to figure it out. Below is a list of already-used definitions (that should not be repeated in the future), and the corresponding version numbers that used them: • 1.0 'g' stands for ‘gRPC’ • 1.1 'g' stands for ‘good' • 1.2 'g' stands for ‘green' • 1.3 'g' stands for ‘gentle' • 1.4 'g' stands for ‘gregarious' • 1.6 'g' stands for ‘garcia' • 1.7 'g' stands for ‘gambit' • 1.8 'g' stands for ‘generous' • 1.9 'g' stands for 'glossy'
  14. So, what is gRPC?

  15. So, what is gRPC? • gRPC is the specification

  16. So, what is gRPC? • gRPC is the specification •

    gRPC is the framework
  17. So, what is gRPC? • gRPC is the specification •

    gRPC is the framework • gRPC is the community
  18. Specification gRPC over HTTP/2

  19. Why HTTP/2?

  20. Why HTTP/2? • Works with existing HTTP/2 infrastructure (encryption, compression,

    load balancing, authentication, etc.)
  21. Why HTTP/2? • Works with existing HTTP/2 infrastructure (encryption, compression,

    load balancing, authentication, etc.) • Many concurrent bidirectional logical binary streams (channels) inside a single TCP/IP connection
  22. Why HTTP/2? • Works with existing HTTP/2 infrastructure (encryption, compression,

    load balancing, authentication, etc.) • Many concurrent bidirectional logical binary streams (channels) inside a single TCP/IP connection • Advanced framing features: prioritization, flow control, server push, etc.
  23. Why not HTTP 1.1?

  24. Why not HTTP 1.1? • No concurrent streams over a

    single connection
  25. Why not HTTP 1.1? • No concurrent streams over a

    single connection • No bidirectional streaming (without hacks like Bayeux or BOSH, or HTTP Upgrade mechanism)
  26. Why not HTTP 1.1? • No concurrent streams over a

    single connection • No bidirectional streaming (without hacks like Bayeux or BOSH, or HTTP Upgrade mechanism) • Headers can’t be compressed
  27. Request example HEADERS (flags = END_HEADERS) :method = POST :scheme

    = http :path = /PublisherService/CreateTopic :authority = pubsub.googleapis.com grpc-timeout = 1S content-type = application/grpc+proto grpc-encoding = gzip authorization = Bearer y235.wef DATA (flags = END_STREAM) <Length-Prefixed Message>
  28. Response example HEADERS (flags = END_HEADERS) :status = 200 grpc-encoding

    = gzip content-type = application/grpc+proto DATA <Length-Prefixed Message> HEADERS (flags = END_STREAM, END_HEADERS) grpc-status = 0 # OK trace-proto-bin = jher831yy13JHy3hc
  29. Framework

  30. What’s inside?

  31. What’s inside? • protobuf as a default message serialization format

  32. What’s inside? • protobuf as a default message serialization format

    • Server and client code generation
  33. What’s inside? • protobuf as a default message serialization format

    • Server and client code generation • Delicacy: context propagation with timeouts and metadata, HTTP/2 PINGs, GOAWAY, etc.
  34. What’s inside? • protobuf as a default message serialization format

    • Server and client code generation • Delicacy: context propagation with timeouts and metadata, HTTP/2 PINGs, GOAWAY, etc. • A lot of (auto-) tuning possibilities: HTTP/2 WINDOW_UPDATE, etc.
  35. Why protobuf?

  36. Why protobuf? • RPC, not only messages

  37. Why protobuf? • RPC, not only messages • Strongly typed,

    useful zero values, backward- and forward-compatibility, canonical mapping to JSON
  38. Why protobuf? • RPC, not only messages • Strongly typed,

    useful zero values, backward- and forward-compatibility, canonical mapping to JSON • Code generation
  39. Why protobuf? • RPC, not only messages • Strongly typed,

    useful zero values, backward- and forward-compatibility, canonical mapping to JSON • Code generation • Effective*
  40. Why protobuf? • RPC, not only messages • Strongly typed,

    useful zero values, backward- and forward-compatibility, canonical mapping to JSON • Code generation • Effective* • … but specification is agnostic to message serialization format
  41. Why protobuf? • RPC, not only messages • Strongly typed,

    useful zero values, backward- and forward-compatibility, canonical mapping to JSON • Code generation • Effective* • … but specification is agnostic to message serialization format • … but please use protobuf v3 by default
  42. How it looks message HelloRequest { string greeting = 1;

    } message HelloResponse { string reply = 1; } service HelloService { rpc SayHello (HelloRequest) returns (HelloResponse); }
  43. How it looks for streaming message HelloRequest { string greeting

    = 1; } message HelloResponse { string reply = 1; } service HelloService { rpc SayHello (stream HelloRequest) returns (stream HelloResponse); }
  44. Metadata

  45. Metadata • Key-value pairs for each request and response

  46. Metadata • Key-value pairs for each request and response •

    Once per RPC call, not per message
  47. Metadata • Key-value pairs for each request and response •

    Once per RPC call, not per message • Can be sent even before request message is received
  48. Metadata • Key-value pairs for each request and response •

    Once per RPC call, not per message • Can be sent even before request message is received • Standard (timeouts, authentication, etc.) and custom
  49. Metadata • Key-value pairs for each request and response •

    Once per RPC call, not per message • Can be sent even before request message is received • Standard (timeouts, authentication, etc.) and custom • Available via context.Context
  50. Error handling

  51. Error handling • 17 standard response codes

  52. Error handling • 17 standard response codes • Some can

    be generated by the framework, some are not
  53. Error handling • 17 standard response codes • Some can

    be generated by the framework, some are not • Custom codes can* be used
  54. Error handling • 17 standard response codes • Some can

    be generated by the framework, some are not • Custom codes can* be used • Always available, even if underlying transport is broken
  55. Error handling • 17 standard response codes • Some can

    be generated by the framework, some are not • Custom codes can* be used • Always available, even if underlying transport is broken • google/rpc/status.proto can be used (embedded or not) for extended statuses
  56. Embedded error message Status { int32 code = 1; string

    message = 2; repeated google.protobuf.Any details = 3; } message MyResponse { Status status = 1; … }
  57. More framework features

  58. More framework features • Retries and back-off strategies

  59. More framework features • Retries and back-off strategies • Server

    reflection
  60. More framework features • Retries and back-off strategies • Server

    reflection • Service configuration
  61. Community

  62. Use cases

  63. Use cases • Backend to backend (microservices)

  64. Use cases • Backend to backend (microservices) • Mobile apps

  65. Use cases • Backend to backend (microservices) • Mobile apps

    • Browsers (both moderns and old)
  66. Use cases • Backend to backend (microservices) • Mobile apps

    • Browsers (both moderns and old) • Ad-hoc scripts (curl and duct tape)
  67. Middlewares

  68. Middlewares • Cascading interceptors

  69. Middlewares • Cascading interceptors • Authentication, validators, panic recovery, logging,

    metrics, tracing, etc.
  70. Alternative transports

  71. Alternative transports • gRPC Web (over HTTP/2 for browsers)

  72. Alternative transports • gRPC Web (over HTTP/2 for browsers) •

    gRPC Websocket Proxy (over HTTP/1.1)
  73. Alternative transports • gRPC Web (over HTTP/2 for browsers) •

    gRPC Websocket Proxy (over HTTP/1.1) • gRPC REST Gateway (both yummy and bitter)
  74. Alternative transports • gRPC Web (over HTTP/2 for browsers) •

    gRPC Websocket Proxy (over HTTP/1.1) • gRPC REST Gateway (both yummy and bitter) • gRPC JSON-RPC Gateway*
  75. Alternative transports • gRPC Web (over HTTP/2 for browsers) •

    gRPC Websocket Proxy (over HTTP/1.1) • gRPC REST Gateway (both yummy and bitter) • gRPC JSON-RPC Gateway* *does not exist
  76. Learn more

  77. Learn more • https://grpc.io

  78. Learn more • https://grpc.io • https://github.com/grpc/grpc/tree/master/doc

  79. Learn more • https://grpc.io • https://github.com/grpc/grpc/tree/master/doc • https://github.com/grpc/grpc-go/tree/master/ Documentation

  80. Learn more • https://grpc.io • https://github.com/grpc/grpc/tree/master/doc • https://github.com/grpc/grpc-go/tree/master/ Documentation •

    https://github.com/grpc-ecosystem
  81. Even more!

  82. Even more! • http://gophercon-russia.ru

  83. Even more! • http://gophercon-russia.ru • https://www.percona.com/about-percona/careers

  84. Questions? https://speakerdeck.com/aleksi