$30 off During Our Annual Pro Sale. View Details »

Cooking gRPC

Cooking gRPC

Alexey Palazhchenko

January 11, 2018
Tweet

More Decks by Alexey Palazhchenko

Other Decks in Technology

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