rain sedge
My team is slowly moving into fully working on this project so I'm curious about the following.
We have decent in house AWS service experience and use CDK stacks (and lambdas) out there for pretty much all our needs.
With our limited exposure to amplify we're considering managing both the cognito user pools and api related things through separate stacks. This leaves us the option to move away from amplify after the MVP period, but also limits our exposure to unknowns and potential limits of it. It also means more people can work and manage the related services outside of the front-end project bit as we have more cdk expertise in house.
Now amplify has a great model for using multiple environments, but we were wondering to what extent we want to let amplify govern the information it needs. In my eyes there is two ways to configure existing services. 1: Using amplify CLI and let it and its amplify environments manage the resource references. 2: Using amplify.configure(). The example from the documentation being: https://docs.amplify.aws/lib/restapi/getting-started/q/platform/js/#manual-setup-reference-existing-rest-api
The second option would mean we have to reference the cognito pools/clients/apis per environment (test/acceptation/prod) in I guess environment variables. This mostly with an eye to prod-related environment variables only being available in our gitlab pipeline. If we do so, are we significantly impeding ourselves from the power of amplify? Would this still allow us to fetch data just fine and have the ability to remove some boilerplate using the API library or are there any significant limits if instead of amplify folder related configuration management, we use amplify.configure() which I guess only starts working/apply from the moment the application starts.
lost dew