Request Response Model

Request-Response is the most famous communication design pattern for the backend, and it is literally everywhere if you think about it. You make a request; the backend processes the request and responds to you. I can keep on writing about it because there is so much going on in this request-response; you might need to kind of remove the layer and discuss it more. So, in a request-response model, the client sends a request. Let's say if I am in a network environment and I am sending a request, the client really needs to define what a request is; the backend really needs to understand what a request is because the data that you send is not just an email or one thing; it's a continuous stream of data, usually in TCP(Transmission Control Protocol), and the server needs to parse the data to look for the start of the request and the end of the request. And then the server parses the request. The server needs to understand the request structure because the client might send three requests; how does it know that this is three requests versus one large request? Where the request begins and where it ends is critical, and this is where backend engineers need to understand it because, believe it or not, the cost of parsing a request is not cheap. Once we parse the request, then we have to process the request on the server side; let's say we receive a GET request, knowing that this is a GET request is one thing; executing the request to fetch an API or query a database is another thing. So these are the processing aspects of requests. of course, when these processes are done, the response is sent back to the client.
So where is it used? The web, basically HTTP, DNS, SSH. Say you send a DNS resolution request: what is the IP address of Google.com? That is a request; it uses UDP(User Datagram Protocol). It puts it in a message; that datagram has a query ID, and when the resolver actually finds the answer, it sends it back to the client. Once it gets a response, it writes it back to the client with the query ID so that we know that this thing we just sent is the answer for this. Another use case is RPC(Remote Procedure Call), a classic programming style that is technically request-response. That request is basically to execute a method. Still, this method happens to be on a remote server instead of the local machine, so you cross the network to execute the method it gives you back.SQL is a request-response protocol: you send a query to the database, and the database processes your query, builds the response, and then responds to you. API'S all sort of API'S(REST,SOAP, GraphQL).
Both the client and server define a request structure, and they have to agree based on the protocol being used. A request has a boundary defined by the protocol and the message format; the protocol defines where it starts and ends, while the message format handles serialization and deserialization. If it is just text like http (Hypertext Transfer Protocol), that means there is no parsing to be done, right? But if it is JSON, XML, Protocol Buffers, or it is your custom message format, then this format has to be understood by both the server and the client. You know how to parse it, and not only parse it, but actually make it back into an object that can be used in your app.
One problem with request-response is that it doesn't work everywhere; let's take a notification service for example, You want to build a notification service that says When someone logs in, I want you to basically tell me that someone just logged in, or someone just uploaded a video, or someone just commented on my story, the notification service doesn’t really jive with the problem because the client has to make a request, but in this case, technically, the backend has the knowledge and the client doesn’t, so one way to solve it is to say Do i have a notification? It works; that is a request-response.
To get a good understanding of how the request-response model works, i decided to build a Custom HTTP Web Server from scratch. Here is a link to implementation of the HTTP Web Server:implementation. Building a server at the raw network layer forces you to handle the exact flow: listening for a connection, reading the raw HTTP request string, parsing its parts, and constructing a valid HTTP response to send back. Another tool I used while learning this was curl. Browsers are great for using HTTP, but they hide a lot of the underlying interaction. curl gives me a much better way to inspect what is happening. For example: curl -v http://google.com. The -v option makes the interaction more visible. I can see information about the request and response rather than treating HTTP as something invisible behind a browser. I also experimented with tracing: curl -v --trace out.txt http://google.com, then inspecting the trace: cat out.txt.The interesting part for me wasn't simply looking at the output. It was asking: What exactly did the client send? And: What exactly did the server send back? That made the request-response model much more concrete.