Amplify-cli: Are multiple files in 'stacks/' supported?

Created on 3 Apr 2019  路  6Comments  路  Source: aws-amplify/amplify-cli

In the documentation, it's implied that only one file called 'CustomResources.json' should be in stacks/. See https://aws-amplify.github.io/docs/cli/graphql?sdk=js.

I tried splitting CustomResources.json into multiple files for better separation of concerns but it seems to cause various 'resolver not found' errors when pushing (see https://github.com/aws-amplify/amplify-cli/issues/1189 for an example).

Are multiple files within stacks/ supported or should we stick to one file?

* Which Category is your question related to? *
graphql api

* Provide additional details e.g. code snippets *

Example errors I ran into:

UPDATE_FAILED QueryMeResolverjson AWS::CloudFormation::Stack Tue Apr 02 2019 18:00:37 GMT-0600 (Mountain Daylight Time) Embedded stack arn:aws:cloudformation:us-east-1:541223640481:stack/<redact>-20190401154033-<redact>-1W6QRH2U2F93D-QueryMeResolverjson-Z0TQPUP5QGHW/232dc040-55a0-11e9-8c89-0eb5200d39ae was not successfully updated. Currently in UPDATE_ROLLBACK_IN_PROGRESS with reason: The following resource(s) failed to update: [QueryMeResolver].

Resource Name: arn:aws:appsync:us-east-1:<redact>:apis/<redact>/types/Query/resolvers/me (AWS::AppSync::Resolver)
Event Type: update
Reason: No resolver found. (Service: AWSAppSync; Status Code: 404; Error Code: NotFoundException; Request ID: 8181100e-55a3-11e9-aa0e-89b15f989174)
URL: <redacted>
dependency-issue graphql-transformer pending-response question

Most helpful comment

Multiple stacks are supported, which is nice, but to solve issues with CloudFormation templates, typically nesting is required. For example, I generated a GraphQL stack with amplify api add-graphql-datasource and the file generated has 247 resources and is more than 480600 bytes.

In the past, I would have separated this by concerns. The existing file would still create the data source and pass it by parameters to child stacks that each manage a table or group of related tables/objects in the database.

When I implemented this, the passed parameters were completely ignored and the stack failed to build correctly.

All 6 comments

I think the answer is yes, but "refactoring" of nested stacks is more than just moving text from one file to another, or renaming a file, it needs to be a multi-step process of deleting a nested stack and its resource then adding the resources back under a new nested stack name.

I have multiple files in the stacks/ folder, everything is working, but I've never tried to rename a template. @hisham is right about refactoring nested stacks.

It took me a while to figure out, because I was trying to "nest stacks" inside of CustomResources.json. But it turns out the CLI will package up any valid JSON stacks in your /stacks folder. It helped me to look under my /amplify/#current-cloud-backend/api/{appname}/build/stacks folder and the ../cloudformation-template.json file to observe how the CLI is packaging things up before it pushes to AWS.

@hisham You're right and it's a multi-step process (first to delete the existing resolver and then to create the same one in another stack). We're looking into this from the service side and seeing if we can optimize for this situation.

Multiple stacks are supported, which is nice, but to solve issues with CloudFormation templates, typically nesting is required. For example, I generated a GraphQL stack with amplify api add-graphql-datasource and the file generated has 247 resources and is more than 480600 bytes.

In the past, I would have separated this by concerns. The existing file would still create the data source and pass it by parameters to child stacks that each manage a table or group of related tables/objects in the database.

When I implemented this, the passed parameters were completely ignored and the stack failed to build correctly.

+1 on this, the whole point of having multiple stacks is to refactor resources in a way that they depend on each other. In my case, I have a need to create numerous additional appsync data sources and pipeline resolvers. My aim is to break it down into multiple nested stacks that have dependencies instead of putting everything in CustomResources.json

Was this page helpful?
0 / 5 - 0 ratings