Update notes

docs/learning_grpc.md

@@ -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
+- In this section we focus on the IDL and the tooling
-
-Here we will focus on the IDL and the tooling, we won't focus on the serialization format.
 
 ---
 
@@ -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.
 
 ---