Serialization and How Data Travels Between Systems

Here’s a thing that’s easy to miss when you’re starting out. Your server has a user object in memory with fields like name, email, age. You want to send it to a mobile app. But you can’t just throw a memory address over the network. Networks only understand bytes.

So you need to convert that object into a string format (like JSON), send it across, and the other side converts it back into a usable object. That’s serialization and deserialization. Sounds fancy, happens on literally every single request.

The Two Directions

Serialization (encoding, marshalling): Object becomes a string. Happens when you SEND a response. Your server turns user object into {"name":"Shubham","age":25}.

Deserialization (decoding, unmarshalling): String becomes an object. Happens when you RECEIVE a request. Client sends {"name":"Shubham"} in the body, your server turns it into a usable object you can access like body.name.

If you’ve ever used JSON.stringify() or JSON.parse() in JavaScript, you’ve done this manually. Most frameworks do it automatically for you behind the scenes.

Why JSON Rules the Web

There are many serialization formats but JSON won for good reasons:

JSON (JavaScript Object Notation)

• Human readable. You can look at it and understand it instantly.
• Every programming language supports it natively or with a one-liner.
• Lightweight enough for most use cases.
• The default for basically all REST APIs.

When you’d use something else:

Protocol Buffers (Protobuf) for service-to-service communication where milliseconds matter. It’s a binary format, about 3-10x smaller and faster than JSON. Google uses it everywhere. You define a schema (.proto file) and it generates code for type-safe serialization.

MessagePack when you want binary efficiency but don’t want to define schemas. It’s basically “binary JSON”, same structure but packed tighter.

XML if you’re working with legacy enterprise systems or SOAP APIs. You’ll encounter it, but never start a new project with it in 2024.

The Invisible Parts

Most of the time, serialization is invisible. Your framework handles it:

On the way in: A POST request arrives with Content-Type: application/json. The framework’s body parser middleware automatically deserializes the JSON body into an object. By the time your handler runs, request.body is already a usable object.

On the way out: You return an object from your handler. The framework serializes it to JSON, sets the Content-Type header, and sends it. You never manually call JSON.stringify().

But understanding that this is happening helps you debug problems. Like when you get "undefined" as a string instead of an actual undefined, or when dates come back in weird formats.

Where Serialization Gets Tricky

Dates are chaos. JSON has no date type. So dates become strings. But which format? ISO 8601 ("2024-01-15T10:30:00Z")? Unix timestamp (1705312200)? Some custom format? Both sides need to agree, and they often don’t.

Naming convention mismatch. Your database uses snake_case (created_at). Your Java code uses camelCase (createdAt). Your frontend might use either. The serialization layer is where you translate between these conventions.

Circular references break things. Object A references B, B references A. Try to serialize that and you get infinite recursion. ORMs are notorious for this when entities reference each other. You need to explicitly handle it by limiting serialization depth or using DTOs.

Security: never blind-deserialize. If you just map raw request JSON directly to a database entity, someone could send {"isAdmin": true} and promote themselves. Always control which fields are allowed through (whitelist approach).

Content Negotiation

HTTP has a built-in mechanism for this. The client tells the server what format it wants:

Accept: application/json

And the server declares what it’s sending:

Content-Type: application/json

In theory your API could support both JSON and XML and let clients choose. In practice, most modern APIs only support JSON and that’s perfectly fine.

Wrapping Up

• Serialization: object to string/bytes (sending)
• Deserialization: string/bytes to object (receiving)
• JSON is the standard for web APIs
• Protobuf/MessagePack for high-performance internal communication
• Watch out for dates, naming conventions, circular refs, and mass-assignment vulnerabilities
• Your framework usually handles the mechanics automatically

Day 5 of 95 | Backend Engineering Series