Add support for Serialize, Deserialize, and Default

[autodidaddict]

The structures that we get from Rust when doing wit-bindgen do not have the Default or Serialize or Deserialize derivations on them. This means that as soon as I attempt to marshal one of these data types somewhere without using a wit function call, I have to manually create my own "mirror types" that have the same structure, but with the serialization attributes on them. Then I have to manually implement either From to convert the wit-bindgen type to my type prior to serialization.

I understand that this kind of activity typically shows up in anti-corruption layers and in an ideal world, the "outside" model and the inside (wit-bindgen) model would never overlap. However, if I have a lot of types and I need to marshal those in and out of my components without making bindgen function calls, I'm stuck redefining every type in my wit world.

Can we get this functionality? If it isn't something that you want on by default, it could be added as a flag to the macro like this:

wit_bindgen::generate!({
    path: "../wit",
    world: "bankaccount-aggregate",
    serializers: true
});

Support for the serializers flag could even be hidden behind a feature flag on the wit-bindgen crate.

[Gearme]

I reckon this is a duplicate of #291. Fwiw, there's issue #58 in the component-model repo that discusses how to address this kind of issue in a more general way (influencing code generation via annotations from a WIT document). That said, the discussion seems to have stalled - not least because it's quite a large can of worms: The solution would have to carry across all language generators and parsers. I'd find it hard to justify solving this issue in a "quick-and-dirty" fashion just for one language. But if you agree that this would be the most sustainable way forward, maybe you can comment/bump there.
That said, I second that it'd be a neat quality of life improvement to be able to specify derive macros at least - whichever way that ends up being implemented.

[Mossaka]

Agreed with @Gearme . I am personally interested in exploring how we can add similar annotations to the tinygo/go bindgen.

[landonxjames]

I'm working with some fairly large and nested types defined in WIT (see example below) and having trouble deriving Serialize/Deserialize in the Rust code for them without explicit support from wit-bindgen. Using serde's remote-derive tends to bottom out whenever a wit_bindgen::rt::vec::Vec<T> or other similarly complicated type appears since there are numerous underlying types that don't have the serde traits implemented.

I can manually mirror all of the types myself, implement the serde stuff on those, and then have a impl From<TypeHelper> for Type (see example below), but that requires quite a few lines of manual code per struct and will be hard to maintain as we add new types to our WIT definition.

Would a possible interim solution be implementing Serialize and Deserialize on all the the wit::rt::* types so that users can at least get something working with remote-derive?

Example of a WIT definition I am working with:

interface alarm-connector-def {

    record alarm-event {
        event-name: string,
        service: string,
        event-type-code: string,
        event-type-category: string,
        start-time: string,
        end-time: string,
        event-description: event-desc-list,
        affected-entities: entity-list,
    }
    
    type event-desc-list = list<event-description>
    
    record event-description {
        language: string,
        latest-description: string,
    }
    
    type entity-list = list<entity>
    
    record entity{
        entity-value: string,
        tags: list<tag>,
    }
    
    record tag{
        key: string,
        value: string,
    }

    parse: func(input: string) -> alarm-event
}

And all the code required to get a working serde impl on it. Not complicated, but verbose:

#[derive(Deserialize)]
pub struct AlarmEventHelper {
    pub event_name: String,
    pub service: String,
    pub event_type_code: String,
    pub event_type_category: String,
    pub start_time: String,
    pub end_time: String,
    pub event_description: EventDescListHelper,
    pub affected_entities: EntityListHelper,
}

pub type EventDescListHelper = Vec<EventDescriptionHelper>;
#[derive(Deserialize)]
pub struct EventDescriptionHelper {
    pub language: String,
    pub latest_description: String,
}
pub type EntityListHelper = Vec<EntityHelper>;
#[derive(Deserialize)]
pub struct EntityHelper {
    pub entity_value: String,
    pub tags: Vec<TagHelper>,
}
#[derive(Deserialize)]
pub struct TagHelper {
    pub key: String,
    pub value: String,
}

impl From<AlarmEventHelper> for AlarmEvent {
    fn from(item: AlarmEventHelper) -> Self {
        AlarmEvent {
            event_name: item.event_name,
            service: item.service,
            event_type_code: item.event_type_code,
            event_type_category: item.event_type_category,
            start_time: item.start_time,
            end_time: item.end_time,
            event_description: item
                .event_description
                .into_iter()
                .map(|desc| EventDescription::from(desc))
                .collect(),
            affected_entities: item
                .affected_entities
                .into_iter()
                .map(|entity| Entity::from(entity))
                .collect(),
        }
    }
}

impl From<EventDescriptionHelper> for EventDescription {
    fn from(item: EventDescriptionHelper) -> Self {
        EventDescription {
            language: item.language,
            latest_description: item.latest_description,
        }
    }
}

impl From<TagHelper> for Tag {
    fn from(item: TagHelper) -> Self {
        Tag {
            key: item.key,
            value: item.value,
        }
    }
}

impl From<EntityHelper> for Entity {
    fn from(item: EntityHelper) -> Self {
        Entity {
            entity_value: item.entity_value,
            tags: item.tags.into_iter().map(|tag| Tag::from(tag)).collect(),
        }
    }
}

[thomastaylor312]

@landonxjames Over in wasmcloud we're running into the same issue with serde. I'm really hoping to get some time to add custom attributes support in the next week or two

[lann]

Somewhat relatedly, I have a serde impl that works with wasmtime::component::Vals: https://github.com/lann/wasmtime-component-serde Not directly applicable here but it would be great if the solution here could be compatible with it.