{"id":35535708,"url":"https://github.com/service-atlas/backend","last_synced_at":"2026-04-02T20:52:28.569Z","repository":{"id":286717449,"uuid":"962314607","full_name":"service-atlas/backend","owner":"service-atlas","description":"An API for tracking software dependencies","archived":false,"fork":false,"pushed_at":"2026-04-01T02:22:53.000Z","size":436,"stargazers_count":1,"open_issues_count":5,"forks_count":1,"subscribers_count":1,"default_branch":"main","last_synced_at":"2026-04-01T04:51:46.104Z","etag":null,"topics":["cmdb","dependency-graph","golang"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/service-atlas.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-04-08T01:15:41.000Z","updated_at":"2026-04-01T02:22:57.000Z","dependencies_parsed_at":"2025-04-08T02:32:56.834Z","dependency_job_id":"7cf0105c-772e-4a25-9dcc-29a95a59c9d1","html_url":"https://github.com/service-atlas/backend","commit_stats":null,"previous_names":["jlpdeveloper/service-dependency-api"],"tags_count":13,"template":false,"template_full_name":null,"purl":"pkg:github/service-atlas/backend","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/service-atlas%2Fbackend","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/service-atlas%2Fbackend/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/service-atlas%2Fbackend/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/service-atlas%2Fbackend/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/service-atlas","download_url":"https://codeload.github.com/service-atlas/backend/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/service-atlas%2Fbackend/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31316008,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-02T12:59:32.332Z","status":"ssl_error","status_checked_at":"2026-04-02T12:54:48.875Z","response_time":89,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cmdb","dependency-graph","golang"],"created_at":"2026-01-04T03:19:43.389Z","updated_at":"2026-04-02T20:52:28.564Z","avatar_url":"https://github.com/service-atlas.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Service Atlas Backend\n![Coverage](https://img.shields.io/badge/Coverage-77.6%25-brightgreen)\n![CodeRabbit Pull Request Reviews](https://img.shields.io/coderabbit/prs/github/service-atlas/backend?utm_source=oss\u0026utm_medium=github\u0026utm_campaign=service-atlas%2Fbackend\u0026labelColor=171717\u0026color=FF570A\u0026link=https%3A%2F%2Fcoderabbit.ai\u0026label=CodeRabbit+Reviews)\n\nA RESTful API service designed to map dependencies between services and provide basic information about services in your ecosystem.\n\n_Note_ This API was designed as a project to learn Go. If you wish to use it, you can, but you should put it behind an API gateway or something to make it secure.\n\n## Overview\n\nThis API allows you to:\n\n- Track services and their metadata (name, description, GitHub repo, etc.)\n- Map dependencies between services\n- Associate releases with services\n- Query service relationships and dependencies\n\n## Features\n\n- Create, read, update, and delete services\n- Map dependencies between services\n- Track service metadata such as:\n    - Name\n    - Description\n    - Database dependencies\n    - GitHub repository\n- Associate releases with services\n- Ability to add technical debt to a service\n- Classify services by operational criticality using Service Tiers (1–4)\n\n## Design Philosophy\n\n### What Service Atlas Is\n\nService Atlas is a tool for understanding and surfacing relationships between systems. It exists to answer one core question: *if something changes or fails here, what else is affected?*\n\nDebt and release tracking exist solely to support risk analysis — they are not project management tools or replacements for your work tracking software.\n\n### What Service Atlas Is Not\n\n**It is not an infrastructure catalog.** An API gateway and the lambdas behind it are one service — the thing your team ships and operates as a cohesive unit. The underlying cloud resources that implement it are irrelevant to the graph.\n\n**It is not a CMDB.** Service Atlas models what engineers think about and own, not every resource that exists in your cloud account. A catalog of 10,000 items where no one can find the 50 things they care about has negative value.\n\n**It is not an incident management system.** It informs incident response by surfacing blast radius and ownership, but it does not replace your alerting, on-call, or postmortem tooling.\n\n### Design Principles\n\n- **Simple by design** — a service requires only a name and a type to exist. Complexity should never be a barrier to adoption.\n- **Logical over physical** — model systems as engineers understand them, not as infrastructure defines them.\n- **Relationships over inventory** — the graph is the value. A service in isolation is just a record.\n- **Advisory not prescriptive** — risk scores support human judgment. They do not enforce policy or predict outcomes.\n- **Engineer-first** — value should flow to the people doing the work, not only upward to leadership.\n\n\n## What is a \"Service\"\nA service is a distinct, independently deployable component of a larger platform. The unit of meaning is logical, not physical — it is the thing your team reasons about, names, owns, and ships.\nService was chosen as the initial use case for this api was to catalog microservices and relations between them. Services can `depend_on` other services and have `releases` associated with them\n\n```mermaid\nflowchart LR\n    id1((Service A)) -- Depends On --\u003e id2((Service B))\n    id1 -- Released --\u003e r1((Release 1))\n    t1((Team A)) -- Owns --\u003e id1\n\n```\n\n## Debt\nThis application supports the recording and tracking of categorized technical debt as part of the database. Technical debt can fall into the categories below.\n\n### Debt Types\n| Type           | Notes                                                         |\n|----------------|---------------------------------------------------------------|\n| code           | code smells or localized poor code quality                    |\n| documentation  | lack of documentation about app purpose, how tos, etc         |\n| testing        | lack of types of testing                                      |\n| architecture   | issues with design choices that affect the entire application |\n| infrastructure | issues with the infrastructure stack the app runs on          |\n| security       | security issues, such as using packages past EOL              |\n\n### Debt Statuses\n| Status      | Notes                                  |\n|-------------|----------------------------------------|\n| pending     | a new debt item                        |\n| in_progress | actively being worked on               |\n| remediated  | a debt item that is no longer an issue |\n\n### Why track technical debt?\nI think adding technical debt (or code rot) is a useful way to track and quantify issues with services. Things that are in your work tracking software (Jira, etc.)\nmay or may not always be picked up in a reasonable timeframe and may not be easily associated with the service in question.\n\n## Neo4j Data Structure\nServices are created under a `Service` object, while releases are created under a `Release` object.\nServices can have a `Depend_ON` relationship that may have a version as part of the relationship\nServices `Released` a `Release`\nServices `OWNS` a `Debt`\n\nServices also include a `tier` property to indicate operational criticality, validated to be an integer from 1 (most critical) to 4 (least critical). If not set, it defaults to Tier 3 (Supporting) behavior.\n\nReleases will always have a date; releases without a date are assigned `now()` as the date. Releases may have an associated url, a version, or both, but require at least the url or a version to be present.\n\n## Installation\n\n### Prerequisites\n\n- Go 1.26 or higher\n- Neo4j database\n- Docker and Docker Compose (optional, for local development)\n\n### Using Docker Compose\n\n1. Clone the repository\n2. Start the Neo4j database:\n   ```sh\n   docker-compose up -d\n   ```\n3. Set the required environment variables:\n   ```sh\n   export DB_URL=neo4j://localhost:7687\n   export DB_USERNAME=neo4j\n   export DB_PASSWORD=password\n   ```\n4. Build and run the application:\n   ```sh\n   go build -o service-atlas ./cmd/service-atlas\n   ./service-atlas\n   ```\n\n## Configuration\n\nThe application is configured using environment variables:\n\n- `DB_URL`: URL of the Neo4j database (default: none, required)\n- `DB_USERNAME`: Username for Neo4j authentication (default: none, required)\n- `DB_PASSWORD`: Password for Neo4j authentication (default: none, required)\n\nThe server listens on port 8080 by default.\n\n### CORS Configuration\n\nThe API enables CORS via middleware. You can control allowed origins and methods via the `CORS_CONFIG` environment variable. If not set or invalid, the following default configuration is used:\n\n```\n{\n  \"AllowedOrigins\": [\"*\"],\n  \"AllowedMethods\": [\"GET\", \"POST\", \"PUT\", \"DELETE\"]\n}\n```\n\nTo provide a custom configuration, set `CORS_CONFIG` to a JSON string with the same shape. Examples:\n\n- Allow a single origin and limit methods to GET/OPTIONS:\n\n```\nexport CORS_CONFIG='{\"AllowedOrigins\":[\"https://example.com\"],\"AllowedMethods\":[\"GET\",\"OPTIONS\"]}'\n```\n\n- Allow multiple specific origins and common methods:\n\n```\nexport CORS_CONFIG='{\"AllowedOrigins\":[\"https://app.example.com\",\"https://admin.example.com\"],\"AllowedMethods\":[\"GET\",\"POST\",\"PUT\",\"DELETE\",\"OPTIONS\"]}'\n```\n\nNotes:\n- The value must be valid JSON; invalid JSON will be ignored and the default will be used.\n- `AllowedOrigins` accepts `\"*\"` to allow all origins or a list of exact origin URLs.\n- Only the specified HTTP methods are allowed for CORS preflight and actual requests.\n\n## API Endpoints\n\nFor more information on endpoints, see the [Bruno Collection](./HTTP_COLLECTION)\n\n## ChangeLog\n### V1.4.0\n_Date: 2025-12-19_\n- Introduces Service Tiers (criticality classification) with `tier` field on Service (allowed values 1–4)\n- Validates tier values and returns `tier` in API responses\n- Supports creating, updating, and querying services by `tier`\n- Defaults existing/unspecified services to Tier 3 behavior\n\n### V1.2.0\n_Date: 2025-11-09_\n- Refactors to use Chi http routing library\n- Adds support for associating teams to services\n- Adds test container tests to neo4j repositories\n\n## Service Tiers (Criticality Classification)\n\n### Summary\nService Tiers introduce a `tier` attribute on `Service` to represent how critical a component is to the overall operation of the platform. This helps reason about impact, prioritize work, and understand dependency risk across the system.\n\n### Tier Model\nUse 4 tiers, where Tier 1 is the most critical.\n\n- Tier 1 — Mission Critical\n  - Core to the platform’s primary purpose\n  - Outage results in total or near-total platform failure\n  - High customer, revenue, or availability impact\n- Tier 2 — Business Critical\n  - Platform remains partially functional if down\n  - Significant degradation of key features or workflows\n  - High user impact, but not a full outage\n- Tier 3 — Supporting\n  - Enhances or supports core functionality\n  - Failures are noticeable but tolerable short-term\n  - Often asynchronous or auxiliary services\n- Tier 4 — Non-Critical / Auxiliary\n  - Minimal operational impact if unavailable\n  - Internal tools, dashboards, or experimental components\n\n### Scope\n- New `tier` field on the Service model\n- Validation of allowed tier values (1–4)\n- Default behavior for existing services: if unset, treat as Tier 3\n- API support for creating, updating, and querying services by `tier`\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fservice-atlas%2Fbackend","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fservice-atlas%2Fbackend","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fservice-atlas%2Fbackend/lists"}