add support for connecting to Azure Front Door with Azure App Configuration store as an origin

[samsadsam]

Usage Patterns

Collection Monitoring Pattern (Recommended)

builder.AddAzureAppConfiguration(options =>
{
    options.ConnectAzureFrontDoor(new Uri("https://your-cdn-endpoint.azurefd.net"))
           .Select("app:*")
           .ConfigureRefresh(refresh =>
           {
               // Monitor entire collection for changes
               refresh.RegisterAll()
                      .SetRefreshInterval(TimeSpan.FromSeconds(30));
           });
});

Sentinel Key Pattern

builder.AddAzureAppConfiguration(options =>
{
    options.ConnectAzureFrontDoor(new Uri("https://your-cdn-endpoint.azurefd.net"))
           .Select("app:*")
           .ConfigureRefresh(refresh =>
           {
               // Register specific keys as sentinels
               refresh.Register("app:sentinel", refreshAll: true)
                      .SetRefreshInterval(TimeSpan.FromSeconds(30));
           });
});

How do we guarantee fresh config when refresh all is triggered?

In the case of when a refresh all is triggered, we add a new token param to the query that essentially triggers CDN to fetch from origin (Azure App Configuration) so that we get the latest configuration. This token is the first change etag we detected, the one that triggered a "refresh all" operation.
It is either a page new etag (Collection Monitoring Pattern) or sentinel key new etag (Sentinel Key Pattern). We treat feature flags the same as collection monitoring.
We keep using this token until a new change happens and a new etag is detected.

[avanigupta]

Note: Correlation-Context header should contain a special tag when ConnectCdn is used.

[jimmyca15]

@samsadsam, @avanigupta led a portal design review recently in which it came up that we should use Azure Front Door as API terminology instead of CDN. There were a couple of reasons.

• Azure CDN is being retired
• We don't support generic CDN, just Azure Front Door

So instead of ConnectCdn as the public method, I believe this will need to become ConnectAzureFrontDoor. Any summaries/supporting APIs would need an update as well.

[zhenlan]

So instead of ConnectCdn as the public method, I believe this will need to become ConnectAzureFrontDoor. Any summaries/supporting APIs would need an update as well.

Any preference between ConnectAzureFrontDoor and ConnectAzureFrontDoorCdn? AFD has many other things than CDN.

[jimmyca15]

So instead of ConnectCdn as the public method, I believe this will need to become ConnectAzureFrontDoor. Any summaries/supporting APIs would need an update as well.

Any preference between ConnectAzureFrontDoor and ConnectAzureFrontDoorCdn? AFD has many other things than CDN.

According to their docs, it looks like the CDN part is implied because "Azure Front Door is Microsoft's advanced cloud Content Delivery Network (CDN)"

In that case I'd say we go with ConnectAzureFrontDoor

[avanigupta]

Looks good, the only remaining work is to rename cdn->afd everywhere.

[samsadsam]

Looks good, the only remaining work is to rename cdn->afd everywhere.

I don’t think we need to do this for internal classes, I think cdn is better than afd as we can support other CDN providers in the future with same internal classes.

My understanding is that we only need to do this for the public apis

cc @jimmyca15

[jimmyca15]

Looks good, the only remaining work is to rename cdn->afd everywhere.

I don’t think we need to do this for internal classes, I think cdn is better than afd as we can support other CDN providers in the future with same internal classes.

My understanding is that we only need to do this for the public apis

cc @jimmyca15

If it's easier to understand by linking the two with afd, then I'm fine with it.

[avanigupta]

Looks good, the only remaining work is to rename cdn->afd everywhere.

I don’t think we need to do this for internal classes, I think cdn is better than afd as we can support other CDN providers in the future with same internal classes.
My understanding is that we only need to do this for the public apis
cc @jimmyca15

If it's easier to understand by linking the two with afd, then I'm fine with it.

My thinking is that if we were starting from scratch today, knowing we’re adding a new API called ConnectAzureFrontDoor, and commit to supporting AFD (not generic CDN) - would we still name classes/interfaces with CDN?

[samsadsam]

@avanigupta @jimmyca15 does it look good now?

[zhiyuanliang-ms]

what is the purpose of this testcase?

[zhiyuanliang-ms]

What we really care about is whether both apps can eventually get the latest configuration from the cdn. I understand what this testcase is doing, but I don't think it is meaningful.