search

liquidvotingio / decidim-module-liquidvoting

GNU Affero General Public License v3.0
4 stars 0 forks source link

Make live API the default config #113

Closed oliverbarnes closed 3 years ago

oliverbarnes commented 3 years ago

Things like precompiling assets or running migrations now barf if the liquidvoting api isn't accessible (the graphql client hits it to fetch the schema each time the code is loaded. Just got bit by this while trying to dockerize the demo.

this PR restricts the dependency to when the app is running in a server process

The server process detection approach is brittle: https://stackoverflow.com/questions/12088025/detect-if-application-was-started-as-http-server-or-not-rake-task-rconsole-etc/12246652#12246652

So instead we're going to let the api be hit in all cases, but distinguish between development and production/test. Loading the module will now hit the localhost api locally and when in development env, and the live api on production and CI.

The CI uses different environments, development (for rake test_app), test (for running tests on the test_app), and needs to hit the live api on both cases.

I'm dropping the environment distinction and making the live API the default. Also adding more comments explaining the usage locally or private networks.

Note:

With this solution, when running tests locally, by default it'll also hit the live api, and k8s teardown will need to be run manually.

The alternative is to export the local env vars use the local api:

export LIQUID_VOTING_API_URL="http://localhost:4000" 
export LIQUID_VOTING_API_ORG_ID="24e173f5-d99a-4470-b1cc-142b392df10a"
sudo -E bin/rails s --port=80

The api teardown can be done by running mix ecto.reset on it.

In other words, I'm opting for keeping the module and CI configs straightforward, in exchange for an extra step in local dev.

davefrey commented 3 years ago

Thank you for tackling this! What about adding a fourth rails environment like ci or similar? I definitely depend on having my specs run against my local api db.

oliverbarnes commented 3 years ago

Thank you for tackling this! What about adding a fourth rails environment like ci or similar? I definitely depend on having my specs run against my local api db.

See my latest description update, for local dev I'm recommending exporting the env vars before running rails s:

export LIQUID_VOTING_API_URL = "http://localhost:4000" 
export LIQUID_VOTING_API_ORG_ID = "24e173f5-d99a-4470-b1cc-142b392df10a"
sudo bin/rails s --port=80

And tearing down the api state with a simple mix ecto.reset.

davefrey commented 3 years ago

LGTM, I like the env var approach 👍