mirror of
https://codeberg.org/JasterV/grpc-slides.git
synced 2026-04-26 18:40:03 +00:00
Update notes
This commit is contained in:
JasterV
parent
ade272333a
commit
ea79735906
1 changed files with 49 additions and 6 deletions
|
|
@ -15,12 +15,17 @@ An idea to extend transfer of control and transmission of data from one machine
|
|||
note:
|
||||
|
||||
- The concept dates back to 1976 [1]
|
||||
|
||||
- Paper written by ANDREW D. BIRRELL and BRUCE JAY NELSON
|
||||
|
||||
- Back in the days building network application required big expertise and was not user friendly
|
||||
|
||||
- They wanted to make it as easy to call a remote service as a local one, very user friendly
|
||||
|
||||
- They wanted to make it efficient (Networks were very slow)
|
||||
|
||||
- They wanted to make it secure (Networks were not secure)
|
||||
|
||||
- RPCRuntime is also known as RPC communications package
|
||||
|
||||
- In that lab, the user-stub and server-stub used to be generated by a program called Lupine.
|
||||
|
|
@ -38,9 +43,13 @@ note:
|
|||
note:
|
||||
|
||||
- google Remote procedure calls
|
||||
|
||||
- Initially created by Google
|
||||
|
||||
- Used to connect microservices across data centers
|
||||
|
||||
- It used to be called Stubby
|
||||
|
||||
- In march 2015 they decided to build and publish a next version called gRPC and make it open source
|
||||
|
||||
---
|
||||
|
|
@ -56,7 +65,9 @@ Code is generated for you batteries included, you must only fill the gaps.
|
|||
note:
|
||||
|
||||
- All the underlying details about networking, encoding & more is handled for you.
|
||||
|
||||
- For clients the feeling must be more of a library one.
|
||||
|
||||
- Some implementations wrap the original C library, some don't.
|
||||
|
||||
---
|
||||
|
|
@ -71,7 +82,7 @@ So we get for free
|
|||
|
||||
note:
|
||||
|
||||
Multiplexing & server push are especially relevant in gRPC
|
||||
- Multiplexing & server push are especially relevant in gRPC
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -92,9 +103,13 @@ Implemented using HTTP/2 headers.
|
|||
note:
|
||||
|
||||
- gRPC metadata can be sent and received by both the client and the server.
|
||||
|
||||
- Headers are sent from the client to the server before the initial request.
|
||||
|
||||
- Headers are sent from the server to the client before the initial response of an RPC call.
|
||||
|
||||
- The links shows a document specifying supported values as metadata.
|
||||
|
||||
- Can be useful for: Authentication & tracing.
|
||||
|
||||
---
|
||||
|
|
@ -114,8 +129,11 @@ note:
|
|||
- Features might differ from language to language
|
||||
|
||||
- **Flow control**: mechanism to ensure that a receiver of messages does not get overwhelmed by a fast sender
|
||||
|
||||
- **Reflection**: Allows for clients without the generated client code to discover the gRPC services on the fly
|
||||
|
||||
- **Health check**: A service is provided to monitor the health of specific services in your server
|
||||
|
||||
- **Retries**:
|
||||
- Enabled by default, with no default retry policy.
|
||||
- By default retries low-level race conditions
|
||||
|
|
@ -133,7 +151,9 @@ https://protobuf.dev/
|
|||
note:
|
||||
|
||||
- Also developed by google
|
||||
|
||||
- Default serialization format supported by gRPC
|
||||
|
||||
- Interface Definition Language supported by gRPC
|
||||
|
||||
[2] https://en.wikipedia.org/wiki/Interface_description_language
|
||||
|
|
@ -149,9 +169,7 @@ note:
|
|||
|
||||
note:
|
||||
|
||||
Explain what an IDL is
|
||||
|
||||
Here we will focus on the IDL and the tooling, we won't focus on the serialization format.
|
||||
- In this section we focus on the IDL and the tooling
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -209,8 +227,11 @@ enum CustomerDeclineRenewalReason {
|
|||
note:
|
||||
|
||||
- Fields are uniquely identified with a numeric tag.
|
||||
|
||||
- When deleting fields, their tag must be marked as reserved to ensure its never used again
|
||||
|
||||
- Enums must always have a 0 variant "UNSPECIFIED" to be used as the default value
|
||||
|
||||
- The engineer must follow a set of good practices to ensure backward/forward compatibility, not everything can be enforced by the compiler
|
||||
|
||||
---
|
||||
|
|
@ -258,9 +279,13 @@ service PolicyManagementService {
|
|||
note:
|
||||
|
||||
- Importing other definitions is allowed
|
||||
|
||||
- "proto3" is the recommended edition to use
|
||||
|
||||
- Packages have to define a namespace
|
||||
|
||||
- Service definition is supported by the language as we see above
|
||||
|
||||
- The 4 types of RPC are supported, above we only see Unary RPCs
|
||||
|
||||
---
|
||||
|
|
@ -293,6 +318,7 @@ note:
|
|||
note:
|
||||
|
||||
- Builds on top of protoc
|
||||
|
||||
- Provides a very easy to use plugin and build system
|
||||
|
||||
---
|
||||
|
|
@ -315,7 +341,8 @@ note:
|
|||
|
||||
note:
|
||||
|
||||
- It exposes already a set of basic reusable services to solve common networking patterns such as timeouts and rate limiting.
|
||||
- It provides a set of basic reusable services
|
||||
such as timeouts and rate limiting.
|
||||
|
||||
---
|
||||
## Tower service
|
||||
|
|
@ -335,8 +362,11 @@ pub trait Service<Request> {
|
|||
note:
|
||||
|
||||
- Tower’s fundamental abstraction.
|
||||
|
||||
- An asynchronous function from a `Request` to a `Response`.
|
||||
|
||||
- It immediately returns a `Future` representing the eventual completion of processing the request.
|
||||
|
||||
- It is a simplified interface making it easy to write network applications in a modular and reusable way, decoupled from the underlying protocol.
|
||||
|
||||
---
|
||||
|
|
@ -353,6 +383,7 @@ pub trait Layer<S> {
|
|||
note:
|
||||
|
||||
- A mechanism to layer services.
|
||||
|
||||
- It is used to wrap services building this way a "layer" pattern
|
||||
|
||||
---
|
||||
|
|
@ -368,7 +399,9 @@ ServiceBuilder::new()
|
|||
|
||||
note:
|
||||
|
||||
A real example of a layered service. Slightly simplified for the sake of the presentation.
|
||||
- An example of the Tower builder pattern to build layered services
|
||||
|
||||
- Slightly simplified for the sake of the presentation.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -388,6 +421,7 @@ A real example of a layered service. Slightly simplified for the sake of the pre
|
|||
note:
|
||||
|
||||
- Build on top of Tower
|
||||
|
||||
- It has first class support for async/await.
|
||||
|
||||
---
|
||||
|
|
@ -405,6 +439,7 @@ note:
|
|||
note:
|
||||
|
||||
- We will focus on code generation, service implementation and client-server implementation
|
||||
|
||||
- Later we will see examples of implementing middleware using Tower Layers
|
||||
|
||||
---
|
||||
|
|
@ -444,6 +479,7 @@ tonic_build::configure()
|
|||
note:
|
||||
|
||||
- prost_build generates types from the message definitions
|
||||
|
||||
- tonic_build generates the Client & Server stubs
|
||||
|
||||
---
|
||||
|
|
@ -629,7 +665,9 @@ note:
|
|||
Simple build of a Tonic Server.
|
||||
|
||||
- The GrpcServer acts as a Router.
|
||||
|
||||
- The GrpcServer doesn't know how to unpack-pack messages, that is handled by each specific server stub.
|
||||
|
||||
- The GrpcServer will be listening to a TCP port like an HTTP2 server.
|
||||
|
||||
---
|
||||
|
|
@ -667,7 +705,9 @@ let _response = client.generate_contract(request).await?;
|
|||
note:
|
||||
|
||||
- We use the Metadata feature to set authorization headers to the request
|
||||
|
||||
- The ClientStub exposes the same API we defined in our protobuf service definition
|
||||
|
||||
- It handles all the packing-unpacking as well as the network
|
||||
|
||||
---
|
||||
|
|
@ -699,7 +739,9 @@ pub struct JwtAuth<T: JwtDecoder, S> {
|
|||
note:
|
||||
|
||||
- This service acts as a middleware intercepting incoming requests before it gets to the inner service `S`.
|
||||
|
||||
- The audience represents the Auth0 audience, which is our API identifier.
|
||||
|
||||
- The jwt_decoder is able to verify tokens.
|
||||
|
||||
---
|
||||
|
|
@ -730,6 +772,7 @@ impl<T: JwtDecoder, S> JwtAuth<T, S> {
|
|||
note:
|
||||
|
||||
- Code is simplified for the sake of the slide.
|
||||
|
||||
- let's assume that `make_unauthorized_response` will build an unauthorized response.
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in a new issue