Serialization and Deserialization: A Practical Guide for Backend Engineers

Serialization and Deserialization: A Practical Guide for Backend Engineers

When building backend systems, we constantly move data between different applications, services, and machines.

A browser sends data to a backend server. The server processes that data and sends a response back. But there is an important question behind this seemingly simple process:

How can two applications written in different programming languages understand the same data?

For example, imagine a JavaScript frontend communicating with a backend written in Rust. JavaScript and Rust have different type systems, data structures, and ways of representing information.

So how does a JavaScript object become something that a Rust server can understand?

The answer involves serialization and deserialization.

What Is Serialization?

Serialization is the process of converting data from its native representation into a standardized format that can be transmitted or stored.

The standardized format allows different applications, programming languages, and systems to exchange information.

For example, a JavaScript application might have an object like:

{
  name: "Nimai",
  age: 25
}

Before sending this data through an HTTP request, the application can convert it into a common format such as JSON.

Conceptually:

JavaScript Object
       ↓
   Serialization
       ↓
      JSON
       ↓
 Network

The JSON representation can then be transmitted to the backend.

What Is Deserialization?

Deserialization is the reverse process.

When the server receives serialized data, it converts that data from the common format into a representation that the server-side application can understand and work with.

For example:

      JSON
       ↓
 Deserialization
       ↓
Rust Struct / Server Object

The server can then validate the data, perform business logic, store information in a database, or generate a response.

When the response is sent back, the process happens again in the opposite direction.

Serialization in a Client-Server Application

Let’s consider a typical web application.

The client could be a browser running a JavaScript application built with React, Angular, Vue, or another framework.

The backend could be running on a local machine or somewhere in the cloud, such as AWS, GCP, or Azure.

The client and server can communicate using different technologies, including:

  • HTTP
  • REST APIs
  • WebSockets
  • gRPC

For a typical REST API, the communication commonly happens over HTTP.

A simplified request looks like this:

Client
  |
  | HTTP Request
  | JSON Data
  ↓
Server
  |
  | HTTP Response
  | JSON Data
  ↓
Client

The client sends data in a standardized format, the server understands it, processes it, and sends a response using a standardized format again.

Why Do We Need a Common Format?

Imagine a JavaScript application sending this object:

{
  name: "John"
}

The backend is written in Rust.

JavaScript and Rust don’t internally represent objects in exactly the same way. The backend therefore needs some agreed-upon representation that both sides understand.

This is where serialization standards become important.

Instead of sending a JavaScript-specific object directly over the network, the client converts it into a commonly understood format.

For example:

JavaScript
    ↓
Serialize
    ↓
JSON
    ↓
Network
    ↓
JSON
    ↓
Deserialize
    ↓
Rust

The client and server don’t need to use the same programming language.

They only need to agree on the format used for communication.

JSON: One of the Most Popular Serialization Formats

There are several serialization formats available.

Some commonly encountered formats include:

Text-based formats

  • JSON
  • XML
  • YAML

Binary formats

There are also binary serialization formats, such as Protocol Buffers, which are commonly used in systems such as gRPC.

For traditional HTTP REST API communication, JSON is one of the most common choices.

What Is JSON?

JSON stands for JavaScript Object Notation.

Despite its name, JSON isn’t limited to JavaScript. It is widely used across programming languages and technologies.

You will commonly encounter JSON in:

  • REST APIs
  • Configuration files
  • Application logs
  • Client-server communication
  • Data exchange between services

One of JSON’s biggest advantages is that it is human-readable.

A simple JSON object looks like this:

{
  "name": "John",
  "age": 25,
  "active": true
}

JSON can also contain arrays and nested objects.

For example:

{
  "name": "John",
  "age": 25,
  "active": true,
  "address": {
    "country": "India",
    "city": "Kolkata"
  }
}

This structure makes JSON useful for representing relatively complex application data.

Basic JSON Rules

There are a few important things to understand about JSON.

An object is surrounded by curly braces:

{
  "name": "John"
}

Object keys are written as strings using double quotes:

"name"

Values can commonly be:

  • Strings
  • Numbers
  • Booleans
  • Arrays
  • Objects
  • null

For example:

{
  "name": "John",
  "age": 25,
  "isDeveloper": true,
  "skills": ["Java", "Rust", "JavaScript"],
  "address": {
    "city": "Kolkata"
  }
}

Objects can therefore be nested inside other objects, and arrays can contain multiple values or objects.

A Real REST API Example

Suppose we have a book application.

A frontend wants to create a new book, so it sends a POST request to:

POST /api/books

The request body might contain:

{
  "id": 1,
  "title": "Backend Engineering",
  "author": "John"
}

This JSON is the serialized representation of the data being sent by the client.

The request travels through the network and eventually reaches the server.

The backend receives the JSON and deserializes it into a representation it can use internally.

Conceptually:

Client Object
     ↓
Serialization
     ↓
JSON
     ↓
HTTP Request
     ↓
Server
     ↓
Deserialization
     ↓
Server-side Object

The server can now use the data to perform its business logic.

What Happens When the Server Responds?

After processing the request, the server may return something like:

{
  "books": [
    {
      "id": 1,
      "title": "Backend Engineering",
      "author": "John"
    }
  ]
}

The response is again represented using JSON.

The client receives this JSON and deserializes it into a representation that its application can work with.

The complete flow becomes:

          CLIENT
             |
      JavaScript Object
             |
       Serialization
             ↓
            JSON
             |
        HTTP Request
             ↓
          SERVER
             |
      JSON received
             |
      Deserialization
             ↓
       Server Object
             |
       Business Logic
             |
       Server Response
             ↓
            JSON
             |
      HTTP Response
             ↓
          CLIENT
             |
      Deserialization
             ↓
     JavaScript Object

This is the basic idea behind serialization and deserialization in client-server communication.

Where Does the OSI Model Fit In?

When data travels over a network, many things happen underneath the application layer.

The OSI model provides a conceptual way to understand network communication through different layers.

At a high level, an application creates data at the application layer. As that data moves through the networking stack, it can be represented and encapsulated in different forms before being transmitted.

Eventually, the data is transmitted over the physical network.

For a backend engineer, however, it is useful to maintain a practical mental model.

You generally don’t need to think about every bit and signal involved every time you create a REST API.

Instead, focus on the application-level contract:

Application
     ↓
JSON
     ↓
HTTP
     ↓
Network

At the receiving end, the networking stack delivers the data back to the application layer, where the server can process the HTTP request and its JSON payload.

Understanding that distinction helps keep backend development manageable without requiring you to work directly with every lower-level networking detail.

Serialization Is Not Only About Networks

Although serialization is heavily associated with API communication, the concept is broader.

Serialization can also be used when storing data.

The general idea remains the same:

Application Data
       ↓
 Serialization
       ↓
 Standard Format
       ↓
 Storage / Transmission

Later, the data can be read and deserialized back into a usable representation.

This is why serialization is an important concept beyond just REST APIs.

Text-Based vs Binary Serialization

Serialization formats can broadly be divided into two categories.

1. Text-Based Serialization

Examples include:

  • JSON
  • XML
  • YAML

These formats are generally easier for humans to read and inspect.

JSON, for example:

{
  "id": 10,
  "name": "Book"
}

This makes debugging API requests and responses relatively straightforward.

2. Binary Serialization

Binary serialization formats represent information in a binary-oriented format.

One well-known example is Protocol Buffers (Protobuf).

Binary formats can be useful when performance, compact message size, or strongly defined schemas are important.

The right choice depends on the requirements of the system.

Serialization vs Deserialization

The easiest way to remember the difference is:

Operation Direction
Serialization Application data → Common format
Deserialization Common format → Application data

For example:

Serialization:

JavaScript Object
       ↓
      JSON

And:

Deserialization:

JSON
 ↓
Rust Struct

When building an API, you will often encounter both processes repeatedly.

Why Backend Engineers Should Understand This

You don’t necessarily need to know every serialization technology in the industry.

Backend engineering is a huge field with many technologies, frameworks, protocols, databases, and serialization formats.

A practical approach is to first understand the fundamental concept.

For HTTP-based REST APIs, understanding JSON serialization and deserialization gives you a strong foundation.

Later, you can learn other technologies such as:

  • XML
  • Protocol Buffers
  • gRPC
  • MessagePack
  • Avro
  • Other serialization mechanisms

The important thing is understanding why serialization exists, rather than memorizing every available format.

Common Misunderstanding: JSON Is Not the Programming Language

A common misconception is that JSON is simply a JavaScript object.

It may look similar to a JavaScript object, but JSON is a data interchange format.

For example, JavaScript can contain many constructs that aren’t valid JSON.

JSON has its own syntax and rules.

That’s why we should think of JSON as a standardized representation of data that different systems can exchange.

The Big Picture

Let’s step back and look at the entire process.

Suppose a user clicks a button in a web application.

The frontend has some application data:

JavaScript Object

The frontend serializes that data:

JavaScript Object
        ↓
       JSON

The JSON is placed into an HTTP request:

JSON
 ↓
HTTP Request
 ↓
Network

The backend receives the request and deserializes the JSON:

JSON
 ↓
Backend Object

The server performs its business logic and creates a response:

Backend Object
       ↓
Serialization
       ↓
JSON

The response travels back to the client:

JSON
 ↓
HTTP Response
 ↓
Network
 ↓
Client

Finally, the client deserializes the JSON and uses the resulting data to update the UI.

That entire process is a fundamental part of modern distributed applications.

Final Takeaway

Serialization and deserialization are techniques for converting application data to and from a common format so that different systems can communicate and understand the same information.

In a typical REST API:

Client
  ↓
Serialize
  ↓
JSON
  ↓
HTTP
  ↓
Server
  ↓
Deserialize
  ↓
Business Logic
  ↓
Serialize
  ↓
JSON
  ↓
HTTP
  ↓
Client
  ↓
Deserialize

The most important thing to remember is that the client and server don’t need to use the same programming language.

A JavaScript frontend can communicate with a Rust, Java, Go, Python, or PHP backend because both sides can agree on a standardized data representation such as JSON.

Once you understand this mental model, concepts such as REST APIs, request bodies, response bodies, API contracts, JSON parsing, DTOs, and binary serialization formats become much easier to understand.

Serialization is essentially about turning application data into a form that can be shared. Deserialization is about turning that shared representation back into something an application can use.

That simple idea is one of the building blocks of modern backend engineering.

Tags:

Leave a Reply