The Serialization API in Base

Inside your worker you work with rich objects: class instances with methods, nested entities, dates. The wire only carries JSON. Serialization is the conversion between the two, and Base gives you an explicit, decorator-driven way to control it, so what crosses the boundary is exactly what you intend, not whatever a generic JSON dump happens to expose.

Why you control it explicitly

The lazy way to send an object is to hand it to a generic JSON stringifier and let it take everything. That is how internal fields leak into responses, how a password hash ends up in an API payload, how a circular reference crashes the request. Base treats serialization as a decision you make per class, not an accident that happens to whatever object you return.

You mark a class as serializable and mark the specific fields that should be included. A field that is not marked does not cross the wire. The shape that travels is the shape you declared, which means adding a sensitive field to a class does not silently add it to your API.

Serialize and deserialize

The API has two directions. Serializing takes one of your objects and produces a JSON-safe representation of it, following the field markings you declared. Deserializing takes that representation and reconstructs the object. Together they are the round trip: object to wire, wire to object.

Serialization also handles the parts of the conversion that are easy to get wrong by hand. An object that refers back to itself, directly or through a chain, is a cycle, and a naive stringifier throws on it. Base lets you choose what a cycle becomes: an error if you want to know, an omission, or a null in its place. The awkward case has a declared outcome instead of a runtime surprise.

Where it fits with REST and RPC

Serialization is the layer underneath the boundaries your API exposes. When a route returns an object, it is serialized on the way out. When a value travels over RPC between workers or from the browser, serialization is what turns it into something transmissible and back. You usually do not call serialize and deserialize by hand in a handler; you declare your classes serializable and let the transport layers use that declaration. The API is there directly for the cases where you do need to control a conversion yourself.

How it relates to validation

Serialization and validation both decorate your classes and both live at the edge, but they answer different questions. Validation asks whether incoming data is acceptable and rejects it if not. Serialization asks what your data looks like on the wire and converts it. A class can be both: validated on the way in, serializable on the way out, with each concern declared on the same fields. If that distinction is what you came for, there is a dedicated post on serialization versus validation; this post is about the serialization side.

The mental model to keep

Serialization is your worker's translator between in-memory objects and the JSON that travels, and you control it by declaration: mark the class serializable, mark the fields that should cross, and decide what a cycle becomes. The transport layers use that declaration so your responses and your RPC payloads carry exactly the shape you intended, not whatever an object happened to hold.