Cooking gRPC

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