Suggestions to schema improvements

[kristianmandrup]

Thanks for the great work. Looks like a huge, important step in the right direction.

Regarding the schema, I'm curious why you decided to inline default: true/false in each deployment configuratiun. What if there are multiple default: true? Which one is the “real” default?

I think each configuration object should have a name, which can be used to assign version names such as “beta”, “canary”, "rc-0" or even relative version numbers etc.

Then you can reference each configuration entry by name instead of by index:

This could in turn be leveraged to allow for the deployments to be configured externally, instead of inlined as follows. This would make it much easier to administer IMO.

{
  "deployments": {
    "default": "beta",
    "load": {
      "beta": {
        "percent": 70
      },
      "canary": {
        "percent": 30
      }
    }
  }
}

Could it be made more flexible to work with Feature/Deployment Flag tools such as Launch Darkly? This would then require custom logic which accesses this config via an API and compares it with the user session role or group to decide which version is dynamically loaded for a given user.

{
  "deployments": {
    "default": "prod",
    "load": {
      "beta": {
        "users": ["beta-testers"]
      },
      "canary": {
        "users": ["canary-testers"]
      }
    }
  }
}

Just some thoughts. Cheers.

[lucamezzalira]

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

[kristianmandrup]

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.