Cooking gRPC

Transcript

1. Parental advisory
   Borken English
   

   View Slide

2. View Slide

3. View Slide

4. View Slide

5. Cooking gRPC
   

   View Slide

6. Who knows what is
   gRPC?
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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'
    

    View Slide

14. So, what is gRPC?
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. Specification
    gRPC over HTTP/2
    

    View Slide

19. Why HTTP/2?
    

    View Slide

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

    View Slide

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
    

    View Slide

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.
    

    View Slide

23. Why not HTTP 1.1?
    

    View Slide

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

    View Slide

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)
    

    View Slide

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
    

    View Slide

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)
    
    

    View Slide

28. Response example
    HEADERS (flags = END_HEADERS)
    :status = 200
    grpc-encoding = gzip
    content-type = application/grpc+proto
    DATA
    
    HEADERS (flags = END_STREAM, END_HEADERS)
    grpc-status = 0 # OK
    trace-proto-bin = jher831yy13JHy3hc
    

    View Slide

29. Framework
    

    View Slide

30. What’s inside?
    

    View Slide

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

    View Slide

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

    View Slide

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.
    

    View Slide

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.
    

    View Slide

35. Why protobuf?
    

    View Slide

36. Why protobuf?
    • RPC, not only messages
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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);
    }
    

    View Slide

44. Metadata
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

50. Error handling
    

    View Slide

51. Error handling
    • 17 standard response codes
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

56. Embedded error
    message Status {
    int32 code = 1;
    string message = 2;
    repeated google.protobuf.Any details = 3;
    }
    message MyResponse {
    Status status = 1;
    …
    }
    

    View Slide

57. More framework features
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

61. Community
    

    View Slide

62. Use cases
    

    View Slide

63. Use cases
    • Backend to backend (microservices)
    

    View Slide

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

    View Slide

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

    View Slide

66. Use cases
    • Backend to backend (microservices)
    • Mobile apps
    • Browsers (both moderns and old)
    • Ad-hoc scripts (curl and duct tape)
    

    View Slide

67. Middlewares
    

    View Slide

68. Middlewares
    • Cascading interceptors
    

    View Slide

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

    View Slide

70. Alternative transports
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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*
    

    View Slide

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
    

    View Slide

76. Learn more
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

81. Even more!
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide