0% found this document useful (0 votes)
2 views7 pages

Serialization Notes

The document provides an overview of serialization and deserialization, focusing on how data is exchanged between different programming languages using common formats like JSON, XML, and Protobuf. It explains the need for a shared format due to differences in native data structures and outlines the process of converting in-memory objects to a portable format before transmission. Additionally, it discusses the types of serialization standards, the specifics of JSON, and when to use different formats based on application needs.

Uploaded by

amarnaniharsh
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views7 pages

Serialization Notes

The document provides an overview of serialization and deserialization, focusing on how data is exchanged between different programming languages using common formats like JSON, XML, and Protobuf. It explains the need for a shared format due to differences in native data structures and outlines the process of converting in-memory objects to a portable format before transmission. Additionally, it discusses the types of serialization standards, the specifics of JSON, and when to use different formats based on application needs.

Uploaded by

amarnaniharsh
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

Serialization · Notes

Serialization & Deserialization — Notes


How language-agnostic data crosses the wire — JSON, YAML, XML, Protobuf
Video walkthrough → exam-ready notes

Contents
1. The Problem — Two Machines, Two Languages
2. The Solution — A Common Format
3. Defining Serialization & Deserialization
4. Where it Fits in the OSI Stack (mental model)
5. Types of Serialization Standards
5.1 Text-based: JSON, YAML, XML
5.2 Binary: Protobuf, Avro, MessagePack
6. JSON Deep Dive
6.1 Syntax rules
6.2 Allowed data types
6.3 Nested structures
7. JSON in Action — Client/Server Demo
8. Why JSON is the 80% Default
9. Cheat-Sheet

1. The Problem — Two Machines, Two Languages


STORY Setup: A React frontend (JavaScript) talks to a Rust backend over HTTP.
JavaScript is dynamically typed, no compilation. Rust is strictly typed, compiled.
Their internal data types have nothing in common.
So how does { name: "Suryanshi", age: 22 } in JavaScript become a
usable Rust struct on the other side — and vice versa?

Native data structures don’t travel. A JS object isn’t a Rust struct; a Python dict isn’t a Go map. The only thing
that actually crosses the wire is a sequence of bytes. Both sides need to agree on what those bytes mean.

2. The Solution — A Common Format


Both client and server agree on a single neutral format. Each side translates between its native types and that
format:
FLOW

Client (JS object) Server (Rust struct)


│ ▲
▼ │
serialize (encode) deserialize (decode)
│ │

Page 1 of 7
Serialization · Notes

▼ │
───────── common format ──────────
(JSON / XML / Protobuf)

• Client serializes its native object → common format string/bytes.


• Bytes travel over the network.
• Server deserializes bytes → its own native type (Rust struct).
• Reply travels back the same way.

EXAM One-line definitions:


• Serialization = converting an in-memory object into a portable common format
(text or bytes).
• Deserialization = the reverse — taking the common format and reconstructing
an in-memory object.

3. Defining the Terms


Operation Direction When you do it

Serialize in-memory object → format (string/bytes) Just before sending a request or


response; saving to disk; logging

Deserialize format (string/bytes) → in-memory object Just after receiving a request or


response; reading from disk/cache

NOTE Other names you’ll see: Encoding / Decoding. Marshal / Unmarshal (Go). Pickle /
Unpickle (Python). Stringify / Parse (JS).

4. Where it Fits — OSI Stack Mental Model


Strictly speaking, serialization happens at the application layer (Layer 7). Below it, the data is broken into TCP
segments, IP packets, Ethernet frames, then voltages on a wire or radio waves — and reassembled on the other
side.
OSI

Layer 7 — Application ← YOU LIVE HERE (JSON, HTTP, gRPC)


Layer 6 — Presentation ← TLS / encryption
Layer 5 — Session
Layer 4 — Transport ← TCP / UDP
Layer 3 — Network ← IP packets
Layer 2 — Data Link ← Ethernet frames
Layer 1 — Physical ← bits, voltages, photons

TIP Backend-engineer shortcut: Don’t worry about what happens between layers 6
and 1. Just trust this: whatever JSON you serialize at the application layer is the

Page 2 of 7
Serialization · Notes

SAME JSON the other side receives at its application layer. The intermediate
transformations are not your concern.

5. Types of Serialization Standards


Two broad families:
Family Members Trade-off

Text-based JSON, YAML, XML Human-readable, easy to debug, larger size

Binary Protobuf, Avro, MessagePack, Thrift Compact, fast, but not human-readable
without a schema

5.1 Text-based formats compared


Format Looks like Typical use

JSON {"key": "value"} REST APIs, web configs, NoSQL documents (the de facto
default)

YAML key: value Config files (Kubernetes, Docker Compose, CI pipelines)

XML <key>value</key> Legacy enterprise APIs (SOAP), older Java/.NET, RSS


feeds

5.2 Binary formats — when JSON isn’t enough


Format Notes

Protocol Buffers (Protobuf) Google’s schema-based binary format. Used by gRPC. Strictly typed, very
compact.

Avro Apache project. Schema travels with data. Used heavily in Kafka pipelines.

MessagePack Like binary JSON. Drop-in for many JSON use cases when size matters.

Thrift Facebook’s alternative to Protobuf — full RPC framework.

NOTE When to consider binary: High-volume internal service-to-service traffic


(microservices), gaming, IoT, anything bandwidth-sensitive. For public REST APIs,
JSON is still the right answer 80% of the time.

Page 3 of 7
Serialization · Notes

6. JSON Deep Dive


JSON = JavaScript Object Notation. Born in JS, now language-independent. Used in REST APIs, config files, logs,
NoSQL DBs.

6.1 Syntax rules


• Object starts with { and ends with }.
• Array starts with [ and ends with ].
• Keys MUST be strings in DOUBLE quotes — no single quotes, no unquoted keys.
• Key–value pairs separated by colon: "key": value
• Multiple pairs separated by commas (no trailing comma).
• Whitespace is ignored — pretty-print or minify freely.

6.2 Allowed data types


Type Example

String "hello"

Number 42, 3.14, -0.001

Boolean true / false

null null

Array [1, 2, 3] or ["a", "b", "c"]

Object { "k": "v" } — can be nested

WARNING JSON does NOT support: undefined, NaN, Infinity, functions, dates, comments,
single-quoted strings, trailing commas. Sending any of these will fail to parse on
the other side.

6.3 Nested example


JSON

{
"id": 123,
"name": "Suryanshi",
"email": "s@[Link]",
"is_active": true,
"tags": ["backend", "analytics"],
"address": {
"country": "India",
"city": "Meerut",
"phone": 9876543210

Page 4 of 7
Serialization · Notes

},
"projects": [
{ "id": 1, "title": "UnisonFlow" },
{ "id": 2, "title": "CodeLens" }
]
}

NOTE Recursive structure: A JSON value can be a string, number, boolean, null, array,
OR another object — and that nested object follows the exact same rules. That
recursion is what lets JSON represent arbitrarily complex data.

7. JSON in Action — Request/Response Flow

Client sends — POST /api/books


HTTP

POST /api/books HTTP/1.1


Host: [Link]
Content-Type: application/json
Content-Length: 67

{
"id": 1,
"title": "Atomic Habits",
"author": "James Clear"
}

Server replies
HTTP

HTTP/1.1 201 Created


Content-Type: application/json

{
"data": [
{ "id": 1, "title": "Atomic Habits", "author": "James Clear" },
{ "id": 2, "title": "Deep Work", "author": "Cal Newport" }
]
}

What actually happened


• JS frontend held a regular JS object → serialized with [Link]().
• That string was sent as the request body with Content-Type: application/json.

Page 5 of 7
Serialization · Notes

• Server-side framework called [Link]() (or language equivalent) → got back a native
object/dict/struct.
• Server ran its business logic, built a response object, serialized to JSON, sent back.
• Frontend parsed the JSON response, used it to render the UI.

EXAM The whole cycle in one sentence: Native object → JSON string → bytes on the
wire → JSON string → native object on the other side.

8. Why JSON is the 80% Default


Reason Why it wins

Human-readable Anyone can open DevTools or curl an endpoint and just READ the data.

Language-agnostic Every major language has a battle-tested JSON parser in its stdlib.

Simple type system Six types cover ~95% of API needs.

Native to JavaScript Browsers parse it natively ([Link] / [Link]) at near-native


speed.

Tooling Postman, Insomnia, BurpSuite, browser DevTools, IDEs — everything


renders JSON nicely.

Self-describing Keys are part of the payload — no separate schema required to inspect
data.

When JSON is NOT the right answer


• Config-heavy files with comments needed → YAML.
• Strict schemas and very high throughput between services → Protobuf + gRPC.
• Legacy enterprise / SOAP integration → XML.
• Streaming structured events through Kafka → Avro.

9. Cheat-Sheet
Concept One-line takeaway

Why serialize? In-memory objects can’t travel — only bytes can. Both sides need a
shared format.

Serialize Native object → common format. Done before sending or saving.

Deserialize Common format → native object. Done after receiving or loading.

Common formats JSON, YAML, XML (text). Protobuf, Avro, MessagePack (binary).

Page 6 of 7
Serialization · Notes

Concept One-line takeaway

JSON keys Always strings, always double-quoted.

JSON types string, number, boolean, null, array, object — no


dates/functions/comments.

JSON content-type application/json on both request and response.

Mental model You touch only the application layer. Lower layers move bytes; that’s
their job.

Default choice JSON for REST APIs. Protobuf for internal gRPC. YAML for configs.

Common names stringify/parse (JS), dumps/loads (Python), marshal/unmarshal (Go),


serialize/deserialize (Java).

End of notes — next stop: request/response handling in code.

Page 7 of 7

You might also like