We usually have a mixed approach for the enums which are likely to change in the future.
let's say WalletTransactionType is an enum which holds Credit, Debit. It may change in future versions when we support transactions with digital wallet or EMI.
Client : Client sdk is generated as if WalletTransactionType properties as a string. We generate the allowed types in the code documentation tags so that as frontend dev tries to set the value, it shows up the documented code to assist him what are allowed.
Server : Server holds the enum type so that its easy to validate for the values passed from client.
Case 1 : Lets say if EMI is added in new version,
V1 : Client sends only Credit, Debit and server validates it fine.
V2 : Client sends all three and server validates it fine.
Case 2 : Let's say we removed Debit option and added EMI.
V1 : Client sends Credit or Debit, server takes the values, takes necessary steps in its v1 version services.
V2 : Works as normal.
Basically we maintain different services, controllers and routers for each version and so does the DTO objects. For a new version, we just clone the existing code and work on it.
If anything breaks, like Case 2, we get a compilation error for V1 versions and we adapt them to match the domain functionality accordingly.
PS : I liked the Unknown extra value though as it can be helpful in some scenarios. I can easily generate unknown for every enum listed in the spec automatically through code generator.
Hope it makes sense.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We usually have a mixed approach for the enums which are likely to change in the future.
let's say WalletTransactionType is an enum which holds Credit, Debit. It may change in future versions when we support transactions with digital wallet or EMI.
Client : Client sdk is generated as if WalletTransactionType properties as a string. We generate the allowed types in the code documentation tags so that as frontend dev tries to set the value, it shows up the documented code to assist him what are allowed.
Server : Server holds the enum type so that its easy to validate for the values passed from client.
Case 1 : Lets say if EMI is added in new version,
V1 : Client sends only Credit, Debit and server validates it fine.
V2 : Client sends all three and server validates it fine.
Case 2 : Let's say we removed Debit option and added EMI.
V1 : Client sends Credit or Debit, server takes the values, takes necessary steps in its v1 version services.
V2 : Works as normal.
Basically we maintain different services, controllers and routers for each version and so does the DTO objects. For a new version, we just clone the existing code and work on it.
If anything breaks, like Case 2, we get a compilation error for V1 versions and we adapt them to match the domain functionality accordingly.
PS : I liked the Unknown extra value though as it can be helpful in some scenarios. I can easily generate unknown for every enum listed in the spec automatically through code generator.
Hope it makes sense.