Use cases / Tech leads, platform and SRE
Knowing what to scale, protect or split before it hurts
The app and the API serve different traffic from one process. The review says so, with the options and what each costs.
The problem
Nobody plans the split, the rate limit or the autoscaler; an incident does. By then the service is big, the team is busy, and the shortcut that caused it is three years old.
What visualdiff does
- Rules read the routes, entry points, doors, libraries and infrastructure the review found: pages and an API in one process, jobs beside the request handlers, admin routes on the public door, a public service with no rate limit, a deployable with no way to scale, no health route, nothing watching it.
- Each piece offers the real options with honest benefits and drawbacks: its own service in this repository, its own repository, or keeping it where it is.
- A model of your choice, through your own key, can add to the list from a fact sheet of the review. It never sees the code, and the option only appears once a key is set.
Every piece names the facts it reasons from and the files to open; the rules see the code, not the traffic, and say so.
Related
- Reviewing pull requests written by agentsAgents open pull requests faster than anyone can read them. Read the 10% that decides whether it is safe.
- Large refactors that hide a behaviour changeA refactor is supposed to change nothing. Find the one line that does.
- Stopping hallucinated dependenciesSlopsquatting: attackers register the package names models invent. Catch them at review.
- Seeing which running systems a change reachesThe diff says rds.tf. The map says orders-db, the API in front of it, and the queue behind it.