[POC] Use resource name to have functions in separate stacks.

[sobolk]

Problem

Certain usage patterns of functions end up with Caused By: ❌ Deployment failed: Error [ValidationError]: Circular dependency between resources:.

This happens is scenarios where it could have been avoided. Just because we pack all functions into same stack and therefore coupling them together.

Changes

This PR explores potential mitigation of the problem in a form of elevating an internal concept of resourceGroup that we're using internally to organize resources into stacks. I.e. this

amplify-backend/packages/plugin-types/src/construct_container.ts

Lines 11 to 15 in 05d98e2

	/**
	* A group name for this generator.
	* This is used by the cache to determine which stack to place the generated construct in
	*/
	resourceGroupName: string;

The usage then looks like this:

export const testFunction = defineFunction({
  resourceGroupName: 'function1'
});

export const myApiFunction = defineFunction({
  name: 'api-function',
  resourceGroupName: 'function2'
});

This could be extended to other categories as well. And potentially provide an alternative way of squashing whole app into single stack.

Validation

There are two test projects used to reproduce the original problem:

1. test-projects/function-stack-1
2. test-projects/function-stack-2

Both deployed successfully with new setting.

Checklist

• If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
• If this PR requires a change to the Project Architecture README, I have included that update in this PR.
• If this PR requires a docs update, I have linked to that docs PR above.
• If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 06e9fea

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR