Skip to main content


Wieder ein paar Fingerübungen in #Rust mit enums, Builder pattern, serde (json) und #Rocket.

Auch in ein paar Sackgassen gelaufen, weil ich sehen wollte, wie man bestimmte Pattern macht oder was man besser lässt. Aber auch sowas ist hilfreich, weil man ein Gefühl dafür bekommt, dass man nicht beliebig sein kann, sondern in #Rust teilweise festere Pfade hat, als in anderen Sprachen.

Für Builder werde ich mal die paar derive crates anschauen, die sowas generieren. Hat jemand Empfehlungen?
#Enum Varianten sind schon eine praktische Sache, kommen aber an ihre Grenzen. Oder besser gesagt, ich habe sie fälschlicherweise als struct missbraucht. Sollte man nicht machen. Allerdings muss ich schauen, was man da konfigurieren kann mit #serde, um das #Json so zu haben, wie ich will.
Aber ich bin fast sicher, dass #struct da sinnvoller ist. Ich habe nämlich einige feste Enums für einen Health-Status (up, down, unknown und out_of_service), aber grundsätzlich kann man beliebige haben. Zu jeden Status gibt es einen HTTP Status Code (2* oder 5*) und ggf. Details.
Ich dachte, perfekt für Enum Varianten, aber Pustekuchen. Viel zu viel bad smelling code und serde serialisert an meinen Erwartungen vorbei (aber nachvollziehbar) und ich muss da umdenken.
Ohne jetzt die Details zu kennen, hört sich für mich nach einer guten Kombination für ein Struct und darin einem Enum-Feld an. Je nach Zusammensetzung könnte hier auf Struct flattening in Kombination mit einer der Enum-Repräsentationen ein sinnvoller Weg sein: https://serde.rs/attr-flatten.html und https://serde.rs/enum-representations.html
Das flatten hat mir gefehlt, damit sollte es gehen. Ich werde das mal ausprobieren. Ein struct benötige ich inzwischen sowieso, da der Health Status Gruppen von Komponenten haben kann (zB eine Persistenz mit Cache und Message Queue bilden zusammen eine Health Gruppe).

Danke für die Idee.