I want to know if there is a way of setting the API path with an ENV variable.
I have the web and API side in AWS, and would like to enable some sort of preview feature flow, to deploy the current feature into a dev stage. I figuring out how to do that with the web side, but I would like to set the API path dinamically.
The goal, is to have different API’s path depending on the stage, if is dev I would like to have a “/dev/api” and if is production maybe the version number like “/1/api”. If there is a way of using a ENV variable I could change that on the build process.
Hi @leoalbin! I’m very interested in what you’re trying to achieve and how you’re trying to do it. Managing dev --> staging (preview) --> production CD is important but hasn’t quite been translated to Serverless app development (yet). Once you get things sorted, please do report back with your solution if you have the time.
The way I’d typically handle this is via the domain; most often using a subdomain. So my setup would look something like:
I’ve never considered swapping out the path but leaving the domain as is — am I correct that this is what you’d like to do?
So .toml doesn’t allow for variables. But you can look downstream to how Webpack consumes the config, which happens in two different files for Development and Production, respectively. I’m going to assume local Development is working fine as is. So here’s the code for Webpack Production Config:
What I suppose you’ll want to do is add Webpack config directly to your project. And from there you can create conditionals based on the environment. Here’s the Redwood Doc about Webpack.
Keep us posted! And if you need help with the Webpack config, definitely post the working code here.
That was going to be my suggestion, too, but may need to add a custom webpack.production config.
It seems that one would want to override and set __REDWOOD__API_PROXY_PATH
And given that webpack.common can use envs
and shows that webpack can access process.env
sop perhaps defining a custom webpack.production.js
and setting __REDWOOD__API_PROXY_PATH to an env might do the trick?
The only other approach I could think of is to at build time (but pre-build) parse redwood.toml, load env, and overwrite the apiProxyPath with the value of that env, save the updated redwood.toml and then proceed with the build.