> For the complete documentation index, see [llms.txt](https://naz.gitbook.io/my-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://naz.gitbook.io/my-docs/backend-learning/serialization_and_deserialization.md).

# Lesson 3: Serialization and Deserialization

## 1. The Problem

We have a client — let's say a browser running a JavaScript app (React, Angular, Vue) — and a server running somewhere remote in the cloud (AWS, GCP, Azure). The client communicates with the server through HTTP, gRPC, WebSockets, or some other means.

The thing to focus on is: how do clients and servers make sense of the data being sent and received?

The client is a JavaScript app. The server can be a Rust app. In JavaScript we might send an object like `{ "name": "some string" }`. After it is sent in the request body and reaches a Rust server — which has completely different data types, is strictly typed, and is compiled — how does the server take this data and make sense of it in its own format, in its own data types?

How does one data type transmitted over a network reach another machine somewhere on the internet and make sense of that data, perform business logic, and send a response that the client can again understand?

```mermaid
sequenceDiagram
    participant C as Client (JavaScript)
    participant S as Server (Rust)

    C->>S: { "name": "some string" }
    Note over S: How does Rust parse this?
    S->>C: { "result": "ok" }
    Note over C: How does JS parse this?
```

***

## 2. The Solution — A Common Standard

If you were asked to solve this problem — two machines in different locations, connected over the internet, needing to exchange data in a way that is language-agnostic — a very obvious solution is coming up with a **common standard**.

This is just a fancy way of saying: you come up with some set of rules, and you ask both the client and the server to agree that this is the format. The client transforms its data from its native language (JavaScript) into this standard format, sends it over the network. The server receives that standard format and converts it into its own native format (Rust structs). When responding, the server converts back into the standard format, sends it, and the client reads it and parses it into JavaScript.

This is the solution: **serialization and deserialization** — converting to and from a common format so that during transmission, data is language-agnostic. Machines, servers, and clients from different domains and different environments are able to make sense of that data and respond to it.

***

## 3. Text-Based vs Binary Formats

There are a lot of serialization standards used in the industry. We'll focus on the most used ones.

**Text-based serialization:**

* **JSON** — the most popular, used \~80% of the time for client-server communication
* **XML**
* **YAML**

**Binary format:**

* **Protobuf** (Protocol Buffers) — the most popular binary format
* Others like Avro, MessagePack

Text-based formats are human-readable. Binary formats are more compact and faster to parse but not human-readable. For HTTP REST API communication, JSON is the dominant choice.

***

## 4. JSON Deep Dive

JSON stands for **JavaScript Object Notation**. From the looks of it, it is very similar to a JavaScript object — that is why it is named that way. But it is not limited to JavaScript. You will find JSON in configuration files, during HTTP REST API transmission, and in log files (JSON is a very popular choice for logging application data during runtime).

### Structure

A typical JSON object:

```json
{
  "name": "some string",
  "age": 25,
  "isActive": true,
  "tags": ["backend", "api"]
}
```

The rules:

* Starts with `{` and ends with `}`
* All **keys** are inside double quotes and are strings — you cannot make any other data type a key
* **Values** can be: string, number, boolean, array, or another object (nested)

### Nested Objects

JSON can be nested. For example, adding an address inside the same JSON:

```json
{
  "name": "some string",
  "address": {
    "country": "India",
    "phone": 3456
  }
}
```

The nested object follows the same characteristics — keys in double quotes, values of any type. That is all there is to JSON.

***

## 5. Client-Server JSON Flow

Let's see how this looks in practice with a Burp Suite demo.

A POST request to `/api/books` sends this JSON in the request body:

```json
{
  "id": 1,
  "title": "Some Book",
  "author": "Some Author"
}
```

All keys are double-quoted strings. The values are a number and two strings. This gets transmitted over the network.

### The OSI Model Context

If you went deep into the OSI model, you know data gets converted from the application layer into data frames, IP packets, and eventually into bits (0s and 1s) transmitted over optical fiber with voltage signals.

As a backend engineer, the mental model to have is: at the application layer, data gets converted into JSON. That is your responsibility. What happens after that — the intermediary steps converting data into different formats — is not your concern. The data travels as bits, reaches the server, gets converted back into JSON on the server side, and the server reads the JSON.

You don't have to worry about the intermediary steps.

```mermaid
flowchart LR
    APP_C["Client App\n(Application Layer)"] -->|"JSON"| OSI["OSI Layers\n(bits, packets)"] -->|"JSON"| APP_S["Server App\n(Application Layer)"]
```

### The Response

The server receives the JSON, takes the `id` and all the information, performs its business logic, and responds with another JSON:

```json
{
  "data": [
    { "id": 1, "title": "Some Book", "author": "Some Author" }
  ]
}
```

The client receives this, parses it, and renders it. The client is able to receive this data from the server and make sense of it. In this case the client is JavaScript, but it could be PHP, Python, or anything else.

***

## 6. Summary

Serialization and deserialization do not have a lot of concepts. It is a phenomena in the backend world that exists — you have to know it exists.

**Serialization** is converting data from a native format into a common standard format before sending it over the network.

**Deserialization** is converting data from that common standard format back into the native format after receiving it.

JSON is transmitted by the client to the server, the server parses it, understands it, makes sense of it, and responds with appropriate data. The client again parses it, understands it, makes sense of it. This whole flow is serialization and deserialization.

They are basically dealing with a standard format so that data is understandable across domains and languages.

***

## Resource

* [Serialization and Deserialization for backend engineers — Sriniously](https://www.youtube.com/watch?v=vzg90tY3uM0)