Update presentation

codebook.toml

@@ -1,4 +1,5 @@
 words = [
+    "birrell",
     "chrono",
     "dyn",
     "idl",

docs/learning_grpc.md

@@ -15,18 +15,15 @@ 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
 
-Five pieces of program are involved when making an RPC call:
-
-User -> User-stub -> RPC communications package (known as RPCRuntime) -> server-stub -> the server.
-
-They auto-generated the client and server stubs:
-
-`The user-stub and server-stub are automatically generated, by a program called Lupine.`
+- In that lab, the user-stub and server-stub used to be generated by a program called Lupine.
 
 [1] WHITE, J. E. A high-level framework for network-based resource sharing. In Proc. National Computer Conference, (June 1976).
 
@@ -48,19 +45,17 @@ google Remote procedure calls
 
 # Why a framework?
 
+<img alt="why a framework diagram" src="./assets/images/framework-diagram.png" width="1000px"/>
+
 gRPC dictates how you will build your network interface.
 
 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.
-
-It is more a framework in the sense of servers. They must use the generated Server Stub, with the only need of implementing the Service interfaces.
-
-Clients will use the generated client Stub. For them the gRPC code will be less intrusive and will feel more like a library
-
-Some implementations wrap the original C library, some don't.
+- 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.
 
 ---
 
@@ -74,18 +69,15 @@ So we get for free
 
 note:
 
-Explain multiplexing and server push
+Multiplexing & server push are especially relevant in gRPC
 
 ---
 
+
 ## 4 types of RPC supported
 
 <img alt="rpc types" src="assets/images/rpc_types.svg" style="width: 70%;" />
 
-note:
-
-Explain that each of these RPC types can be specified on the protobuffers IDL
-
 ---
 ## Metadata
 
@@ -97,32 +89,33 @@ 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 and from the server to the client before the initial response of an RPC call.
-
-On the link I show, they document the supported values for metadata
-
-Can be useful for: Authentication & tracing
+- 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.
 
 ---
 ## And many more features
 
-- **Health checking** (Service-specific health checking)
-- **Interceptors** (Middleware for RPCs)
-- **Reflection** (Service discoverability & ease debugging)
-- RPC automatic & manual **cancellations**
-- Call **retries**
+- Service-specific **health checking**
+- Request **interceptors**
+- **Reflection** for better debugging & discoverability
+- Configurable call **retries** via retry policies
+- RPC **cancellations**
 - **Flow control** for streaming
-- **Load balancing** (Client requests can be load balanced between multiple servers)
+- Client RPC **load balancing**
+- ...
 
 note:
 
-It is important to explain that these features might differ from language to language, since it depends completely on how each of them implements gRPC
+- Features might differ from language to language
 
-- **Flow control** is a mechanism to ensure that a receiver of messages does not get overwhelmed by a fast sender. Flow control prevents data loss, improves performance and increases reliability.
+- **Flow control**: mechanism to ensure that a receiver of messages does not get overwhelmed by a fast sender
 
-- **Reflection**: Explain that we won't go in detail about reflection but that I believe we should research more about it since it can be useful for better developer experience
+- **Reflection**: Allows for clients without the generated client code to discover the gRPC services on the fly
 
-- **Health check**: gRPC specifies a standard service API ([health/v1](https://github.com/grpc/grpc-proto/blob/master/grpc/health/v1/health.proto)) for performing health check calls against gRPC servers. An implementation of this service is provided, but you are responsible for updating the health status of your services. It is pluggable, and some languages might not provide it.
+- **Health check**: A service is provided to monitor the health of specific services in your server
 ---
 
 # Protocol buffers