* Please describe which feature you have a question about? *
Rewrites and Redirects
* Provide additional details*
I plan on having a bunch of rewrites and redirects and would feel more secure if I could save them in my repository. Is it possible to have the rewrite data saved in a config file like the amplify.yml file?
Another benefit of this approach is the rewrites & redirects can differ per connected branch, which can be helpful as things change over time.
Oh and if possible in this process it would also be nice if env vars can be referenced somehow in the rewrites so that secret things can be left in the env vars as usual.
We are experiencing the same issue, it would be great if we can limit the scope of the rewrites and redirects by branch.
Another benefit of this approach is the rewrites & redirects can differ per connected branch, which can be helpful as things change over time.
@smakinson @dbrunet73 if you would like to setup redirects per branch, one workaround is to create two amplify console apps and re-connect the same repo: you will be able to setup different redirects then.
@swaminator I'm looking at using a reverse proxy rewrite to point to proxy a rest api url and the url format is:
https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/
since stage_name needs to be provided I would like to be able to proxy the dev stage_name in the dev environment and the prod stage_name in the prod environment, etc. Perhaps this feature request could solve this? Or maybe we need a similar override option like the env vars have? Or maybe I'm just missing how to do it? 馃槃
By the way, after taking a pause on checking out Amplify console and coming back to it only months later, it's encouraging to see the good progress being made. Thanks for the hard work.
This would be a helpful feature to manage this configuration with the rest of the application instead of tweaking things on a config page.
This is super important for agile workflows, please prioritize. thanks!
Great idea here - this would simplify on-boarding new members who don't need access to AWS.
Currently the best option it to do this via CDK
Most helpful comment
Another benefit of this approach is the rewrites & redirects can differ per connected branch, which can be helpful as things change over time.