Default app config across app types

[shurwit]

In #358 we discussed the file structure to handle version control for app configs, however it would be inconvenient to define a separate app config for each app type as currently required when in most cases the configs would be almost identical across platforms. To address this, we should allow a default app config to be created for the whole application, and allow specific fields to be overridden for each platform. If a version is not specified in these platform-specific config file names, these patches should be automatically applied to all config versions unless a platform specific patch for that version is also defined. See the example below:

File tree

/
    dev/
        illinois/
            illinois_app/
                config.1.1.0.json
                config.1.2.0.json
                config.1.5.0.json
                web/
                    config.json
                    config.1.2.0.json
        other_university/
            other_university_app/
                config.1.0.0.json
                config.1.1.0.json
                ios/
                    config.1.0.0.json  
    webhook-config.json

webhook-config.json

{
    "organizations": {
        "illinois": "0a2eff20-e2cd-11eb-af68-60f81db5ecc0",
        "other_university": "4344f988-23ea-44ce-952b-38414cdfa9e5"
    },
    "applications": {
        "illinois_app": {
            "id": "2bca8159-1d0f-40b9-bf15-d17ce366669e",  // This is the app_id
            "types": {
                "android": "edu.illinois.rokwire.android",
                "ios": "edu.illinois.rokwire.ios",
                "web": "app.rokwire.illinois.edu"
            }
        },
        "other_university_app": {
            "id": "a77c2eb4-eb5a-499a-84ec-db90f7ea707a",
            "types": {
                "android": "edu.other.rokwire.android",
                "ios": "edu.other.rokwire.ios"
            }
        }
    }
}

dev/illinois/illinois_app/config.1.2.0.json

{
    ...
    "appName": "Illinois App",
    "platformType": "mobile",
    "settings": {
        "example_setting": 1
    },
    "platformBuildingBlocks": {
        ...
    },
    ...
}

dev/illinois/illinois_app/web/config.json

This patch will be applied to all config versions in dev/illinois/illinois_app unless a version specific patch is defined for that version (eg. dev/illinois/illinois_app/web/config.1.2.0.json)

{
    "platformType": "web"
}

dev/illinois/illinois_app/web/config.1.2.0.json

This patch will be applied on top of dev/illinois/illinois_app/config.1.2.0.json instead of dev/illinois/illinois_app/web/config.json

{
    "platformType": "web",
    "settings": {
        "example_setting": 2
    }
}

Edit: The merged result of the patches on top of the base files should be stored/cached rather computing on each API requests to load the configs to optimize these requests. This will mean that changes to the base files will need to trigger loading and updating each associated patch in the database/cache. We also need to ensure that the base files are processed before the patches when merging. As a side note, if the webhook-config file was changed, this must be processed before any other file when a webhook request is received.

[mihail-varbanov]

Hi @shurwit.

Your idea of merging app config content from different sources across platforms sounds great.

I am just wondering whether the same logic can be applied by splitting config content across app versions because normally there are just a few differences between two consequent versions. Will this bring better flexibility or it would just make the things more complex without a clear benefit of this? For now my feeling is that we would rather NOT to do this but I am curious what the others think about this?

[shurwit]

Hi @shurwit.

Your idea of merging app config content from different sources across platforms sounds great.

I am just wondering whether the same logic can be applied by splitting config content across app versions because normally there are just a few differences between two consequent versions. Will this bring better flexibility or it would just make the things more complex without a clear benefit of this? For now my feeling is that we would rather NOT to do this but I am curious what the others think about this?

Hi @mihail-varbanov, this is an interesting point. In my opinion, the reason this model works well for platforms is that there is a very limited number of platforms each of which will apply one patch on top of a single base. I think for the versions it may get somewhat confusing. We could have a single base config file and then apply a patch for each version always on top of this base file, but as things change over time, this would likely get messy and difficult to maintain. If we instead apply patches on top of the previous version, this will create a very long chain of patches that will be difficult to follow.

Let me know if you had some other implementation in mind that you think would work better. Thanks again!