add fundamentals of backend engineering and protocols

This commit is contained in:
steinkirch.eth, phd 2023-07-15 12:36:39 -07:00
parent 941083eb8f
commit 4cf49ba50b
6 changed files with 84 additions and 20 deletions

View file

@ -13,21 +13,35 @@
<br>
* **[communication](communication/)**
* **[communication patterns](communication/)**
* Request Response model
* Synchronous vs. Asynchronous workloads
* Push
* Polling and Long Polling
* Server Sent Events
* Publish Subscribe (Pub/Sub)
* Server-Sent Events
* Publish-Subscribe (Pub/Sub)
* Multiplexing vs. Demultiplexing
* Stateful vs. Stateless
* Sidecar Pattern
<br>
* **[execution patterns](execution/)**
* backend execution patterns
* the process, the thread, the cpu time
* reading and sending socket data
* the listener, the acceptor, the reader
* single listener, acceptor, and reader thread execution pattern
* single listener, acceptor, and multiple readers thread execution pattern
* single listener, acceptor, readers with message load-balancing execution pattern
* multiple accepter threads on a single socket execution pattern
* multiple listeners, acceptors, and reader with socket-sharding execution pattern
* backend idempotency
* nagle's algorithm
<br>
* **[protocols](protocols/)**
* protocol properties
* protocol properties
* OSI model
* internet protocol
@ -41,8 +55,10 @@
* gRPC
* WebRTC
<br>
* **[HTTP](https/)**
* https communication
* https over TCP with TLS 1.2
@ -54,21 +70,6 @@
<br>
* **[execution](execution/)**
* backend execution patterns
* the process, the thread, the cpu time
* reading and sending socket data
* the listener, the acceptor, the reader
* single listener, acceptor, and reader thread execution pattern
* single listener, acceptor, and multiple readers thread execution pattern
* single listener, acceptor, reader with message load balancing execution pattern
* multiple accepter threads on a single socket execution pattern
* multiple listeners, acceptors, and reader with socket sharding execution pattern
* backend idempotency
* nagle's algorithm
<br>
* **[proxy and load balance](proxy_and_lb)**
* proxy vs. reverse proxy
* Layer 4 vs. Layer 7 load balancers
@ -91,6 +92,7 @@
* **[gcp](code/gcp)**
* **[chef](code/chef)**
* **[kafka](code/kafka)**
* **[protocol demos](code/protocol_demos/)**
<br>

View file

@ -0,0 +1,7 @@
const fs = require("fs");
console.log("first");
fs.readFile("file.txt", (err,data)=> console.log(data.toString()));
console.log("second");

View file

@ -0,0 +1 @@
gm anon

View file

@ -0,0 +1,12 @@
{
"name": "demo_sync-async",
"version": "1.0.0",
"description": "",
"main": "async.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": ""
}

View file

@ -0,0 +1,10 @@
const fs = require("fs");
console.log("first");
const res = fs.readFileSync("file.txt");
console.log(res);
console.log("second");

View file

@ -119,6 +119,10 @@ curl -v --trace marinasouza.xyz
#### Async workload is everywhere
- async programming (promises, futures)
- async backend processing
- async commits in postgres
- async IO in Linux (epoll, io_uring)
- async replication
- async OS fsync (filesystem cache)
<br>
@ -126,6 +130,29 @@ curl -v --trace marinasouza.xyz
### Push
<br>
#### pros and coins
- real time
- the client must be online (connected to the server)
- the client must be able to handle the load
- polling is preferred for light clients
<br>
#### basic idea
1. client connects to a server
2. server sends data to the client
3. client doesn't have to request anything
4. protocol must be bidirectional
<br>
#### used in
- RabbitMQ (clients consume the queues, and the messages are pushed to the clients)
<br>
@ -133,6 +160,11 @@ curl -v --trace marinasouza.xyz
### Polling
<br>
#### basic idea
- when a request takes long time to process (e.g., upload a video)
- the backend want to sends notification
<br>