as @joshzamor recommend I was about to use feature flag in performance task for supply lines but I’ve encountered one issue. Most of the work for this ticket will be adding REST expand the feature to Supply Lines which will require a complete rework of DTO classes connected with this resource. If we want to preserve old code to use feature flag then 2 separate DTO classes for Supply Lines are needed which then causes complication in the controller method:

we need to return 2 different classes so we probably need to use ResponseEntity<?> which causes sonar issues

for a lifetime of feature flag, rest-api validation must handle both responses
I’m not sure if using feature flag for this case is the way to go. What do you guys think?

Overall we need to stop breaking our API, so hopefully this case warrants it (see my concerns in the performance thread). An approach that works both with breaking changes and feature flags is to:

Break the API by leaving the old API where it is, and introduce and run concurrently the new incompatible version at a different URI. e.g. /api/stockCardSummaries and /api/v2/stockCardSummaries. This approach isn’t really related to feature flags, rather it helps limit the damage caused when an API is broken.

Use the feature flag on the front-end to select which API it’s using when enabled or disabled. In your question, you could have the UI use the old, presumably under-performant API, when the flag is disabled, and the newer, more performant API, when enabled.

That’s how I’d approach using feature flags here, however I do want to reiterate that I have a reservation about over using the expanded REST representation pattern.

thank you for the response. I think that your approach is a good option and I’ll try to implement it. As I said using feature flags for contract breaking changes requires some additional work. I’ll update you how work goes and add you to reviews.