Feature Description
Replace the reliance on a separate, external geo-ip-database service with an integrated, locally utilized library (like a Go or Node.js library that reads a local database file) for Geo-IP lookups within the OASM platform.
Problem or Need
The current system architecture, which includes a dedicated geo-ip-database service, introduces unnecessary complexity, additional operational overhead (managing, monitoring, and scaling another service), and potential network latency for simple database lookups.
By using a local library and a static database file (e.g., MaxMind GeoLite2), we can reduce the deployment footprint, simplify the system architecture, and improve performance by eliminating a network hop for every Geo-IP query. This change is crucial for a more lightweight and efficient worker service execution plane.
Proposed Solution
- Remove the separate
geo-ip-database service from the Docker Compose and overall architecture.
- Integrate a robust Geo-IP library (e.g., a native library that reads
.mmdb files) directly into the services that require this functionality (Worker Service and potentially Core API).
- Update the worker service initialization to load the Geo-IP database from a local path/volume.
- Update the deployment instructions and/or build process to account for the necessary database file acquisition and mounting.
Alternatives Considered
Additional Context
This change primarily affects the Worker Service and its dependencies. It's a key step towards reducing service sprawl and achieving a more performant and easily deployable system, especially for Docker Compose and Kubernetes users.
Code of Conduct
Feature Description
Replace the reliance on a separate, external
geo-ip-databaseservice with an integrated, locally utilized library (like a Go or Node.js library that reads a local database file) for Geo-IP lookups within the OASM platform.Problem or Need
The current system architecture, which includes a dedicated
geo-ip-databaseservice, introduces unnecessary complexity, additional operational overhead (managing, monitoring, and scaling another service), and potential network latency for simple database lookups.By using a local library and a static database file (e.g., MaxMind GeoLite2), we can reduce the deployment footprint, simplify the system architecture, and improve performance by eliminating a network hop for every Geo-IP query. This change is crucial for a more lightweight and efficient worker service execution plane.
Proposed Solution
geo-ip-databaseservice from the Docker Compose and overall architecture..mmdbfiles) directly into the services that require this functionality (Worker Service and potentially Core API).Alternatives Considered
Additional Context
This change primarily affects the Worker Service and its dependencies. It's a key step towards reducing service sprawl and achieving a more performant and easily deployable system, especially for Docker Compose and Kubernetes users.
Code of Conduct