Automatic conversion of enum to sse::Event

[jbirnick]

• I have looked for existing issues (including closed) about this

Feature Request

Have a way, by means of the power of macros, to automatically convert an enum like

enum MyEventType {
    EventOfKindOne,
    SecondKindOfEvent,
    EventWithSomeData { description: String, amount: u64 },
}

to an axum::response::sse::Event. In this case, the event name should correspond to the name of the enum variant, and the event data should be the value(s) that the enum holds, say formatted in JSON.

Motivation

This gives an easy way to work with sse::Events. Usually an enum like the above one will be present anyways, and so right now one has to write a manual conversion method.

Proposal

For serializing the data, serde's Serialize should be used. For the "top level", however, there are two options.

The first method I thought about was to directly use the Serialize trait also for the top level. In that case:

1. the user would derive Serialize for the enum
2. we write a custom Serializer for sse::Event which first checks that it's an "enum", then sets the event name based on the variant, and for deeper "depth" uses the Serializer from serde_json to set the event data

However, then I thought it might be better to come up with an own macro for the top level, called something like JsonEvent or so.
This would then implement maybe Into<sse::Event>, and do the same thing. (It checks that it's an enum and that all the variants implement Serialize, and then into() would do the same thing as described above.)
The advantage of this approach would be I guess that one can add own functionality with attribute macros, allowing for example to use the "comments" feature of events or to specify which variant should be serialized as the "default" event ("message event") in the SSE standard (then the name of the variant would be ignored).

One could also (I guess in both proposals) add functionality to let the user select which Serializer is used for the data, if they want to use a format different from JSON.

Alternatives

I don't see any nice alternatives. Right now one has to manually convert.

PS: I'm happy to (try to) implement this, but please let me know what you think and how it should be implemented, with as much detail as possible!

[jplatte]

Hey. This seems like a pretty niche and simultaneously opinionated feature to me, so I don't think think it makes sense for us to accept it into axum and maintain it.

However, this also doesn't have to be in axum. You can make a separate crate for this, and to make it easy to discover, make a PR adding a link to the repo or crates.io page to our ECOSYSTEM.md file.

If you're looking for resources on how to write your own proc-macro, I wrote a few blog posts about it on https://blog.turbo.fish (though I haven't updated them to syn 2 yet, which changes attribute parsing and a few smaller things). You could also have a look at how the derives in axum-macros work.

[jbirnick]

I'm fine with moving it to another crate, but why is it opinionated? I mean every SSE event has a name and some data, so it's really natural to represent it in rust with an enum. (And then it would be natural to have an easy conversion method to Event.)

If you think there is a less opinionated way to make working with events easy, please tell me. That's why I asked for feedback in my post. I want to make a non-opinionated interface which all people like, and I'm happy to draw from the learnings of people with more Rust experience than me.

In particular, is it perhaps possible to move this thread to "Discussions", so I can get feedback from other people?

[jplatte]

Maybe it's not that opinionated but you're only going to need an enum if you want to store different events together as the same (Rust) type in a collection. Otherwise, you could have one struct per event type, which may or may not have a field representing (part of) the event type.

[jplatte]

Also, to respond to this specific bit of your message:

If you think there is a less opinionated way to make working with events easy, please tell me.

I really think that there is no way to do that. Opinionated is not bad though, it's just that axum tries to be pretty minimal.. so having both a less opinionated lower-level and a more opinionated higher-level API around SSE, something that I think is not used by a large share of axum users, seems wrong to me.

[jplatte]

Last reply for now, take all of what I say on this topic with a grain of salt. I've never used SSE myself so maybe I misunderstand some things.