As an application developer I would like to the option to recursively delete an application,

[rikgibson]

At the moment fn delete app <app-name> deletes an app and all of it's routes/functions/triggers. This behaviour is a bit brutal and should instead be optional, and by default shouldn't be allowed. So instead, attempting to delete an app with any child elements by fn delete app foo would simply respond with You cannot delete an application that contains functions or triggers.

fn delete app can then be extended to support two additional options:

1. --cascade that will delete all child elements in bottom-up order, with an initial Application "foo" contains 3 functions and 5 triggers, are you sure you want to delete it? message and confirmation.

2. --dry-run - this will output a list of elements that would be deleted if fn delete app foo --cascade were executed.

This would also depend on the /apps DELETE API being changed to only delete an application if it were empty. The CLI would instead recursively call DELETE on each /trigger, /function and /app endpoint.

[msgodf]

Perhaps the more conventional --dry-run might be more suitable than --impact?

[hibooboo2]

Id also say use cascade not recursive...

[rikgibson]

Updated above to reflect entirely-reasonable comments...

[msgodf]

Is it difficult for the server to check whether an app has any associated functions or triggers? (i.e. whether it is or isn't empty).

[gviedma-zz]

I think we shouldn't do any cascading deletes server/API-side. Instead, we could have sugar in the CLI to retrieve all resources associated with a function, recursively deleting them via their APIs prior to deleting the app. This would also be the most portable across CLI providers, since not all implementations will be able to support cascading deletes server-side.

[tcoupland]

@gviedma i think that is what's being proposed. "The CLI would instead recursively call DELETE on each /trigger, /function and /app endpoint."

[zootalures]

We don't need this now - super low priority!