Clean up API URL environment variables #3821
Labels
💻 aspect: code
Concerns the software code in the repository
🧰 goal: internal improvement
Improvement that benefits maintainers, not users
🟧 priority: high
Stalls work on the project or its dependents
🧱 stack: api
Related to the Django API
Current Situation
As part of the API migration to openverse.org we will need to have a clean switch over of the "canonical" URL for the application from the .engineering domain to the .org domain. However, the current API configuration does not make this easy, with many hard-coded references to the .engineering domain.
Suggested Improvement
We should consolidate the API domain information into a set of two new environment variables, with all other related domains derived from these two:
CANONICAL_DOMAIN: str
ALTERNATIVE_DOMAINS: list[str]
We should then make the following changes:
BASE_URL
withCANONICAL_DOMAIN
and removeBASE_URL
CSRF_TRUSTED_ORIGINS
set to[BASE_URL] + [f"https://{domain}" for domain in ALTERNATIVE_DOMAINS]
ALLOWED_HOSTS
Django setting to use[CANONICAL_DOMAIN] + ALTERNATIVE_DOMAINS
instead of reading fromALLOWED_HOSTS
environment variableReplace all hard references to
api.openverse.engineering
in the documentation toCANONICAL_DOMAIN
.We can do the following cleanup as well:
LOAD_BALANCER_URL
usage. See https://github.com/WordPress/openverse-infrastructure/pull/804 for rationalisation, where the environment variable is removed entirelyUSE_X_FORWARDED_HOST
, which enables a header we never useBenefit
Reduce the number of changes necessary to change the "canonical" domain of the API from the .engineering domain to .org.
Additional context
There are two things to consider with these changes: how to deploy them directly, and then how to use these new variables during the migration.
To deploy these specific changes:
BASE_URL
andALLOWED_HOSTS
environment variables.This follows our basic zero-downtime approach to environment variable management.
To use these variables during the migration:
ADDITIONAL_DOMAINS
.api-staging.openverse.org
as the canonical domain, and no additional domain. For production, we'll haveapi.openverse.org
as the canonical domain, andapi-production.openverse.org
as an additional domain.The text was updated successfully, but these errors were encountered: