Customize default route on domain root level

[Feature] request

Current status

• Routing like in Web API 2
  • was implemented with v0.7.10532
  • see https://github.com/Azure/azure-webjobs-sdk-script/pull/743
• Website for default route
  • was implemented with v0.8.10564
  • see https://github.com/Azure/azure-webjobs-sdk-script/pull/813; can be deactivated with app setting AzureWebJobsDisableHomepage

Feature request

• Define a Azure Function which responses to requests on the default route on domain root level; e.g.: https://myfunction.azurewebsites.net/ calls function MyHttpCSharp1 -> resolved with Azure Functions Proxies
  • in 02/2017 with v1.0.10758, see Azure App Service Blog and Azure Functions Proxies documentation
  • https://github.com/Azure/azure-webjobs-sdk-script/issues/969 resolved an issue with incorrect routing of the last URL segment if it includes a dot
• Define the path to a custom website which responses to requests on the default route on domain root level: e.g.: https://myfunction.azurewebsites.net/ calls website /home/site/wwwroot/mywebsite/index.html -> not resolved completely, but there is a workaround how to serve static websites with Azure Functions and Proxies
  • see Proxies docs mentioned above and Serving an HTML Page from Azure Functions
  • serverside rendering for SPAs might be possible as well (I will add an update on this later)
  • ASP.NET (core) (MVC) support is not possible yet (I will open another issue on this)
  • serverside logic can be implemented directly inside a Function which composes a dynamic custom HTTP response

Possible implementation

App setting AzureWebJobsDefaultRoute:

1. defaultPage Standard website (“Your Azure Function App is up and running.”) -> default value
2. emptyPage Empty website
3. customPage Custom website
4. function Custom Azure Function

AzureWebJobsDisableHomepage would be obsolete in this scenario.

Detailed settings in host.json:

{
    // Configuration settings for default route:
    "defaultRoute": {
        // Defines the path for a custom website which will respond to requests to the default route.
        // Requires app setting "AzureWebJobsDefaultRoute" value "customPage" to be processed. 
        "customWebsitePath": "/home/site/wwwroot/mywebsite/index.html",
        // Defines the Azure Function which will respond to requests to the default route.
        // Requires app setting "AzureWebJobsDefaultRoute" value "function" to be processed. 
        "functionName": "MyHttpCSharp1"
    }
}

Assumption

An Azure Function needs to have a defined route to use custom routing incl. parameters. If the function gets triggered via the default route on domain root level the response uses default values for parameters which may be defined in the function code (e.g. run.csx in C#).

[mikezks]

IMO the core topics of this issue are resolved now. I suggest to sum up any additional issues connected with this one and to open new ones if there is need for it. Thanks a lot to all of you who contributed actively here.

[ricklove]

Yes, it works now! #969

(At least with proxies)

A cutting edge website can now be built with a single consumption plan azure function app:

• Azure Function with it’s web api
• A function proxy that points to static resources (either a Function or Blob Storage or whatever)
• Azure CDN
  • Custom domain with free SSL for https
  • Pointing to the Azure Function
  • Query String Pass through for running against the web api
  • Static Files (No Query String) get served by the CDN

Bonus (Global Web Api):

If desired, it might be possible to have multiple api endpoints across the globe (I haven’t tested this):

• Setup Azure Functions in different regions around the world (1 per continent maybe?)
• Use Azure Traffic Manager to point to these Azure Functions
• Point the Azure CDN to the Azure Traffic Manager

Now when a client uses the query string to hit the web api, it will pass through the Azure CDN and route through the Azure Traffic Manager to the nearest Azure Functions App.

Of course your distributed azure function apps will have to use storage queues or something to push their data back to your main region, but your clients are going to have the fastest website and web api no matter where they are in the world.

This is great.

Once, I test this, I will be moving our future production to this architecture.