Philosophy of Scryr
Understanding should be something you can build on.
A shared model is more useful when it fits into the way you already build software. Scryr makes the model executable, portable, and reusable beyond a single view. These principles guide what we build and how we develop it.
For the research behind these choices, read Case for Scryr ↗.
Make understanding maintainable.
Architecture knowledge should be easy to review and revise alongside the software it describes. A typed .scry model gives that knowledge a durable home in code.
We use Python so teams can compose models with familiar imports, functions, and packages. Scryr’s checks cover formatting, lint, types, serialization, and diagram rules.
Fit into the project you already have.
Adopting architecture tooling should not require reorganizing your application. Scryr’s CLI manages its own Python runtime and dependencies, leaving your application’s virtual environment unchanged.
When your model needs additional packages, project mode uses your declared, locked dependencies in Scryr’s managed environment.
Keep the model useful outside Scryr.
Your system model should be available to the rest of your tools. JSON carries its data; JSON Schema makes its structure available to consumers in other languages.
Scryr exposes schemas for Manifest, Forge, and Diagram. Use them in your own catalogs, configuration checks, and status tools.
scryr inspect schema --path index.scryThe command returns individual schemas under models. Select the matching schema, then generate types for your application:
- TypeScriptjson-schema-to-typescript ↗
- Goquicktype ↗
- Javaquicktype ↗
- Rusttypify ↗
- Swiftquicktype ↗
- Pythondatamodel-code-generator ↗
- C++quicktype ↗
Start with a question, then choose the view.
A useful view helps someone investigate: follow a request, identify a service’s dependencies, or understand an incident. Named diagrams and typed queries let teams choose the right scope.
Documentation and external links connect that view to supporting tools. The same structured data can also power your own visualizations and investigation tools.
Develop in the open. Check the boundaries.
Scryr is built from a Python SDK, a Rust CLI and server, and a React diagram. Changes to the model must stay consistent across the code that produces it and the tools that consume it.
Our contribution workflow uses isolated worktrees, shared mise tasks, and component checks. Cross-component changes coordinate serialization, API types, and generated frontend contracts so the pieces can evolve together.