Compose CLI Command Schema
Opened this issue · 2 comments
Is there an existing issue for this?
- I have searched existing issues, it hasn't been reported yet
Use case description
Framework currently follows a command format in the CLI where the action is the first action followed by an optional resource type and then whatever flags the command may require. However as new features such as Compose were added, we did not adhere to this standard and instead introduced further fragmentation where you would run Compose commands with different syntax.
In V4, we are going to keep the framework syntax as is, there will be no changes there. However we are going to revise the CLI command standards for Compose & Extensions.
We are going to introduce the following basic schema,
serverless <SERVICE/RESOURCE> <ACTION>
The goal is to have Compose and EXT adhere to this model going forward.
Examples
serverless-compose.yml
# Framework Service
service-a:
path: ./service-a
# EXT Service
service-b:
path: ./service-b
Framework Service serverless.yml
service: aws-node-express-api
frameworkVersion: '4'
provider:
name: aws
runtime: nodejs20.x
functions:
api:
handler: handler.handler
events:
- httpApi: '*'
Extension Service serverless.yml
my-extension:
extension: my-extension@latest
my-extension-two:
extension: my-extension@latest
So with these files we can then run commands in the following ways,
Run Deploy on a specific service in Compose
serverless service-a deploy
Run a command on a specific extension instance in Compose
serverless service-b my-extension deploy
Run Deploy function on a specific framework service in Compose
serverless service-a deploy function -f myApi
Proposed solution (optional)
No response
If we do want to be able to perform more granular commands in a Service from a Compose file, this seems like it fits nicely without changing the UX.
# In serverless.yml
serverless deploy function -f myApi
# In serverless-compose.yml
serverless service-a deploy function -f myApi
100% @ac360 I should have clarified better, but my intention was to not change how framework services work. So your examples are exactly what I intended. The examples currently are more for Extensions and Compose in general.