Suggestions to schema improvements about frontend-discovery HOT 2 OPEN

Thanks for sharing your suggestions!

it's a good point on the boolean value for the default value, we will think about it.
on the other side I got a few questions:

1. why using a string over a version number? The rational is that version numbers are unique, but labels refer to different versions over time. so what would be the plus of this approach in your opinion?
2. looking at your proposal, I guess you have added the versions and load object for extracting the default parameter. But why load? it's because you are balancing through a canary or blue-green deployment?
3. in the last snippet, would you set the percentages? or it's just a role based approach where 100% of the beta-testers will be redirected to the beta version?

For the record, we tried to stay away from external systems for getting a clear path to deliver the solution otherwise we should have a lot of work for handling changes on their services and that's not the purpose of this project.
However the schema is flexible enough to integrate to be integrated in whatever system you need

from frontend-discovery.

Thanks for the reply. The above reflects minimal understanding of the underlying mechanics, usage etc. based primarily on a few videos I watched from the microfrontend conference, which sparked my interest.

1. My suggestion would be to both have a version number which is unique, such as referring to a git sha but also a logical name which then can be looked up and which maps to a different version number over time. I think having only version would make it hard to distinguish "what is what" unless coupled with such metadata in some other way or place.

2. The load was mainly to reflect more accurate naming, based on the percentage load mechanics as I understood it (ie. "load balancer" for progressive deployment).

3. I meant for it to be able to work nicely with tools such as Feature Flag systems, not that it be integrated directly as required tooling. It's just a very natural fit for progressive deployment and fine-grained deployment control.

Im general, I think I now understand that the proposed format is not really the configuration schema, but more like the data delivery package which the frontend-discovery service responds with?

Ideally there would be a configuration schema which is decoupled from the actual data package returned, in order to reduce duplication and make the configuration more generalisable across, which is essentially what I attempted to do in my proposal. Cheers.

from frontend-discovery.