Overview

• This would allow apps that can serve multiple routes
• Changes needed:
  • App record - Needs to record multiple app names supported
  • CLI - Accept additional app name parameters
  • Router: Send multiple app routes to the app
• Example:
  • App name: ecommerce
  • App name / page routes: /search, /product
  • Static files: /ecommerce-app
  • API calls: /ecommerce-app
  • Base path: none

To-Do

• Update db-lib to allow specifying additional top-level "AppNames" to be routed to this app
  • Consider whether aliases should be per-version, this would allow an existing app to be replaced with a multi-app without disruption (the version published that is an alias will take effect when it is requested specifically or when it is set as the default version) - A challenge with this is that it could require setting the version for each alias app on each release --- an alternative would be to allow this but to also allow the rules to be aliases to the primary app rules
  • Read the app names first - If each of them is an alias to the current app name, or they do not exist, then it's ok - If one of them is a real app then reject the request?
• Store the extra AppNames as top-level records of a different type (can allow showing them in the UI, optionally, but primarily allows looking up these "AppNames" to determine if there is an app to handle a route)
• Update router-lib cache to handle the multiple app name indices to a single set of data
• Update router-lib to have additional AppName's resolved to real AppName before lookup of SemVer
• Add unit and integration tests