Getting unexpected results in API Gateway from cloudformation - amazon-web-services

Question

I am somewhat new to writing yaml files and deploying them. I have one built from things that I have worked on in the past, but it is producing results that I don't understand and I believe that this is causing a CORS error when I used the API Gateway (It works using insomnia/postman).
Here is the YAML file.
AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: Storygraf backend API
Globals:
Function:
Timeout: 3
Resources:
ExpressApi:
Type: AWS::Serverless::Api
Properties:
StageName: prod
StageName: dev
ExpressLambdaFunction:
Type: AWS::Serverless::Function
Properties:
Environment:
Variables:
CodeUri: ./
Handler: lambda.handler
MemorySize: 512
Runtime: nodejs14.x
Timeout: 30
Events:
ProxyApiRoot:
Type: Api
Properties:
RestApiId: !Ref ExpressApi
Path: /
Method: ANY
cors: true
ProxyApiGreedy:
Type: Api
Properties:
RestApiId: !Ref ExpressApi
Path: /{proxy+}
Method: ANY
cors: true
I don't really understand the ProxyAPIRoot and ProxyAPIGreedy settings, but I have run the deployment with and without that section and gotten the same results.
I am also attempting to create two stages on the API gateway - one for production and one for development but it occurs to me that I don't really understand the stages very well and the result that I am getting has a "dev" stage (which is correct) and a "Stage" stage, which is not correct.
Here are the resources and stages for the resulting gateway.
Why is there are "Stage" stage and not a "prod" stage?
What is the proxy? Is it causing my CORS problem?

Answer 1

You have to create separate SAM YAML files for different environments. You cannot specify two stages in the same YAML file. If you want to deploy the complete stack in one YAML file, I suggest you switch to pure Cloudformation template, then you would have a lot more flexibility on defining resources.
You can checkout this link and create multiple stages.
Regarding the /{proxy+} resource, it will capture all the requests, like /products, /users/1. Whereas, the / resource will only respond to requests to the endpoint root url, i.e / only.