Open mbrodala opened 3 years ago
Hi @mbrodala, thanks for reporting this issue. As the entrypoint.js file is generated once, I think we should let people implements their own logic in this file to retrieve the right value for this variable. Personally, in my project, I prefer using a dot env file containing the right value for the different environments I use.
When you generate your code for the first time you can use the env API_PLATFORM_CLIENT_GENERATOR_ENTRYPOINT
to set the correct value of your entrypoint if it helps.
Yeah, I noticed the support for environment variables. But this wouldn't really help in our case since the API is accessed differently via CLI and web as mentioned.
Also my impression so far is that I should be able to drop the generated code at any time and re-generate it to get the latest updates/fixes from the templates of this package. This currently requires me to override the entrypoint.js
after each re-generation.
Using .env
is a possible solution but needs to be taken into account when deploying to an environment.
Description
There should be an option to have a dynamic entrypoint when generating client code.
Currently the API endpoint passed to the generator is also used as entrypoint. This is not optimal:
Example
Running the generator with
http://apache/api/
will generate all code and lead to exactly this being set inconfig/entrypoint.js
. Now accessinghttp://app.local/<resource>
will fail sinceapache
is a host name internally resolved in a Docker Compose setup while the setup is accessed viaapp.local
from the host machine.Currently we work around this by adjusting
entrypoint.js
like this after generating the code:Maybe this or similar could be integrated for dynamic entrypoints.