Skip to content

Isolate serde DTOs

No due date 40% complete

We currently have three crates where (de)serialization plays a pivotal role

  1. RPC
  2. Gateway
  3. Storage

All three rely in some fashion on the derived serde code for types from common and crypto crates.

This is an issue because it makes it extremely difficult to change these types without accidentily tweaking the serde definition of DTOs in separate crates. Unfo…

We currently have three crates where (de)serialization plays a pivotal role

  1. RPC
  2. Gateway
  3. Storage

All three rely in some fashion on the derived serde code for types from common and crypto crates.

This is an issue because it makes it extremely difficult to change these types without accidentily tweaking the serde definition of DTOs in separate crates. Unfortunately, #[derive(Serialize, Deserialize)] is the defacto standard operating procedure and it quickly leads to such coupling if one isn't careful.

To decouple and prevent this in the future, we should aim at removing serde entirely from the common and crypto crates. This is the point at which this milestone will be deemed completed.

The proposed solution for each of the three crates will be slightly different, though maybe this will prove false as the implementations progress.

  1. RPC: mostly serialization involved, and a small bit of deserialization. Cares about supporting multiple versions.
  2. Gateway: mostly deserialization, very little serialization. No versioning to speak of.
  3. Storage: equal serialization and deserialization. Both required for every type and they must match. Some blobs require versioning, but that's the blobs problem.
Loading