[App Service] [Discussion] Shorten appservice command group name to just "app"

[lostintangent]

I'd love to discuss whether we could shorten the appservice command group to just app (or equivalent) in order to improve the ergonomics around frequent use. The use of az instead of "Azure" feels so fluid to type (as does nsg, vm, nic, acs, acr, etc.), and I wonder whether we couldn't apply a similar naming abbreviation "principal" for App Service, in order to improve the efficiency of using its command on a regular basis, while balancing intuitiveness/discoverability.

Personally, I don't find the use of <TAB> for auto-completing long command names to be very ergonomic, which is why I've thrown out the possibility of shortening names vs. relying on tab completion. Others may find this acceptable, so I'm just providing one input, which may not be that useful. Apologies if this conversation has already happened. I just wanted to throw it out there while the App Service module was still in beta, and could potentially make a breaking change like this.

UPDATE: As discussed below, an alternative solution to this could be to "flatten" out the appservice command group and provide top-level support for web apps itself (e.g. az webapp). I personally prefer this solution, and would support it over the above previous proposal

[stewartadam]

imho az as or az appsv would be better to avoid confusion with Azure AD apps (az ad app).

[yugangw-msft]

@lostintangent, @stewartadam
Chatted with AppService team on this. We plan to flatten out the command structures. appservice plan becomes appservice-plan and appservice web becomes webapp.
The webapp was chosen over general terms of like app, mainly for easier discovering, considering we have close to 40 top categories now. And the name is still short enough.

[lostintangent]

What about "web" instead of "webapp"? Does the app suffix actually add anything here? I'm cool with "appservice-plan", but I wonder whether we couldn't just repurpose the "appservice" group to be specific to the plan. That way, "appservice create" was the equivalent of "appservice plan create".

I'd be happy either way, I'm just thinking out loud.

[yugangw-msft]

web was proposed but deemed too general to be in the CLI, and also inconsistent with terms used in existing docs.
appservice is a general term which would mean each individual offering like mobile, webapp, 'logic', etc. Adding plan to be explicit is reasonable.
I care less on the plan now. Since on webapp create we will create/reuse a plan automatically, and the plan will mostly become transparent.

[lostintangent]

Sounds good!

[stewartadam]

The -plan suffix part makes sense, but what's the plan to unify branding around the other app types (e.g. API, logic, mobile) then? As well, what will happen to existing scripts that make use of today's appservice category?

[tjprescott]

@stewartadam raises a great point. I believe that API and mobile apps are really just webapps under the hood, but logic apps aren't. Are we going to have "logicapp" and "webapp" as top level resources (my vote is an emphatic no).

You could also have a structure with "app" as the root and place "service-plan" as a subgroup inside, while the commands to create and manage apps would be at this basic "app" level. This is a bit of an inversion from the norm, but I think it could be justified based on (1) the fact that the appservice team wants the concept of "app service plans" to be essentially transparent, and (2) the fact that we can (and it has been recommended) that we create the service plan when we create the webapp if it doesn't already exist.

Also, to answer @stewartadam's question, scripts using the existing appservice subgroup would break. This is why it is crucial to get this command structure locked down before this command module goes GA (it is currently in preview).

[yugangw-msft]

(The discussion with appservice group is still on-going, and I will incorporate all feedback here)
The plan is to get all app types to be on-top like az logicapp. There are business needs and market effort to align with, hence followed the requirements of visibility and discoverability to their service users. Nesting under a general term is not favorable option to service teams, even though it makes logic sense to CLI team. Also very few users I know of will use across all commands in CLI, rather just limited to couple of services' command-set, and they do want to find those commands quickly, and mostly by just following the market term to spot a category in CLI.

[tjprescott]

FTR, webapplinux is a terrible name.

[yugangw-msft]

This still stays at the level of an idea circulated internally and there is no plan on board to really do it at this point

[stewartadam]

Note that the portal also further distinguishes between bot, API, web, etc apps as well. A decision to use top-level namespaces will need to be clear on how to brand these types of apps (if it is going to at all), and if so then any new possible new classes of apps going forward.

imho, a single top-level group like @tjprescott described is best and provides the most flexibility going onward. Understood that there are other pressures for naming, my 0.02 is we should do what makes the most sense for the CLI tooling to make sure it's consistent and easy to use. As it stands, Logic Apps are branded underneath App Service: https://azure.microsoft.com/en-us/services/logic-apps/