Best practices around exporting/import backend

[kekami]

I'm building a project and the number of custom resources are growing. Most/all examples show custom resources added to backend.ts, and I wonder what the best approach would be if I were to extract resources into separate files. My question is mainly on how backend should be handled.

E.g. if I have a custom RestAPI construct, should I be doing this

new RestAPI(restApiStack, 'rest-api', {
  functions: {
    createCustomer: backend.createCustomerHandler.resources.lambda,
    createEmployee: backend.createEmployeeHandler.resources.lambda,
  },
});

vs

just importing backend from within the RestApi construct? Not sure if exporting backend would result in circular dependencies from a CDK perspective.

[josefaidt]

Hey @kekami :wave: thanks for raising this! I do think we need a bit of an explainer on how to work with custom resources in practice (with other Amplify-managed resources). To answer the immediate question think of backend.ts as your App.tsx but for your backend, and custom resources as your backend components. It's where everything comes together and resources are wired into the backend.

For custom resources (or custom constructs), you'd define construct props and set the prop values' type to the corresponding CDK resource. There's a couple of blog posts on writing custom constructs, like this one from bobbyhadz.com. Thinking about these custom resources as components, defining the inputs as props allows your construct to be portable.

Not sure if exporting backend would result in circular dependencies from a CDK perspective.

It may create a circular dependency, but it will create a circular reference if you were to import the backend into your custom construct, then import and initialize your custom construct in the backend.ts file

[kekami]

Hey @kekami :wave: thanks for raising this! I do think we need a bit of an explainer on how to work with custom resources in practice (with other Amplify-managed resources). To answer the immediate question think of backend.ts as your App.tsx but for your backend, and custom resources as your backend components. It's where everything comes together and resources are wired into the backend.

For custom resources (or custom constructs), you'd define construct props and set the prop values' type to the corresponding CDK resource. There's a couple of blog posts on writing custom constructs, like this one from bobbyhadz.com. Thinking about these custom resources as components, defining the inputs as props allows your construct to be portable.

Not sure if exporting backend would result in circular dependencies from a CDK perspective.

It may create a circular dependency, but it will create a circular reference if you were to import the backend into your custom construct, then import and initialize your custom construct in the backend.ts file

Sorry for the late response @josefaidt . Thanks for the clarification and an absolutely amazing response! 💫