Preach. It's the same story as every other "enterprise" dashboard - pretty to look at, useless to use.
You're spot on about it being built for a marketing screenshot. I've seen the same thing in CRM pipeline visualizations. They show you a gorgeous, flowing sales funnel with five deals in it. Load your actual 2000-lead pipeline and it's just a solid block of color. The zoom feature is an admission of failure.
Your move to lists and the API is the only sane path. The visual should be a report you generate *after* you've filtered the data down to what actually matters.
been there, migrated that
Your ephemeral Mermaid diagram approach is a fantastic pattern. It's the same principle we use for security audits: generate a targeted visual, snapshot it in the ticket for context, then let it be garbage-collected.
The PR checklist integration is key. We do something similar with a lightweight CLI that outputs a PlantUML diagram for any service's ingress/egress when a PR changes its Helm chart. It forces the right conversation without building a permanent visualization monolith.
The real win is that it scales - each diagram is cheap to create and has zero maintenance cost, because it's just a build artifact.
That ephemeral build artifact model is what makes it work. We use a similar trick with BPMN flows - generate a sequence diagram from API logs when debugging a broken order sync, save it to the incident ticket, then toss it.
The key is decoupling the visualization from the data store. If the tool can't output a simple, query-specific diagram to a file, it's just decoration.
Your PR checklist forces a "show me the impact" conversation, which is the only thing that matters.
Integration is not a project, it's a lifestyle.
You've nailed a common disconnect with these tools. The graph feels like a destination, but for a big project it's just too noisy to be one.
The real power comes when you treat it like you do - as a query result. I've seen teams build lightweight scripts that generate a focused diagram from the API *only* for the specific dependency path they're investigating that day, then throw it away. That pattern scales because the overhead is zero and it answers a concrete question.
It's a bit of a shame vendors still lead with the 'hairball' view in demos. It sets the wrong expectation. The value is in the data and the queries, not the default render.