Project Graph by graphif: a desktop node canvas for non-linear thinking

What Project Graph solves, and who the README says it is for

A whiteboard is good at capturing a thought and bad at keeping it. A text outliner keeps order but flattens relationships. Project Graph sits between the two: it is a desktop application for drawing node graphs, where each idea is a node and each connection is an edge you drag into place. The README frames it as a tool for brainstorming, teaching design and project planning, and lists three diagram families it supports: directed acyclic graphs (DAGs), tree structures, and logic relationship networks. Those three are not decoration. A DAG is what you draw when you are sequencing tasks with dependencies; a tree is what you draw when you are decomposing a topic; a relationship network is what you draw when the structure is genuinely cyclic and no hierarchy applies. The README names three audiences. Designers making creative flowcharts and brainstorming relationship maps. Teachers building course outlines and knowledge graphs for classroom presentation. Developers mapping module dependencies, workflows and system architecture. The common thread is that the artifact is spatial, not linear, and the user wants to move nodes around rather than reorder bullet points. If your output is a paragraph of prose, this is the wrong shape of tool.

How the node canvas, history and autosave fit together

The repository layout tells you more about the architecture than the README does. The top level contains app/, packages/, utils/, docs/, docs-pg/, benchmarks/, plus an nx.json and a pnpm-workspace.yaml, so this is an Nx monorepo with pnpm workspaces rather than a single-package app. The topics list canvas, canvas2d and canvasjs alongside reactjs, tailwind, vite and tauri-app, which points at a React front end rendering to a 2D canvas, bundled by Vite and wrapped in a Tauri shell for the desktop binary. The root package.json confirms the toolchain: scripts run through Nx (nx run-many -t dev tauri:dev), formatting is Prettier with prettier-plugin-tailwindcss, linting is ESLint 10 with typescript-eslint, and tests run under Vitest. The node engine requirement is Node >= 26.0.0, and the package manager is pinned to [email protected]. The README describes the editing model in one line: drag and drop to create, edit and adjust nodes. It also states that every operation is undoable and redoable, and that document changes are recorded automatically so data is not lost. Those two features are the ones that decide whether a canvas tool is usable for a long session, and the README treats them as core rather than optional. What it does not describe is the persistence format, the undo stack depth, or where the automatic backup is written on disk.

Installing Project Graph and drawing a first DAG

The README gives two installation routes and no package-manager route. The first is a direct download: it links to https://graphif.dev/release/latest and says to pick the build for your platform. Cross-platform support for Windows, macOS and most Linux systems is listed as a feature. The second route is building from source, and for that the README defers to a development guide at https://graphif.dev/docs/contribute rather than reproducing the steps. So the commands below are not from the README; they are the scripts declared in the root package.json, which is the only build information in the repository itself. Note the engine constraint before you start: Node >= 26.0.0, [email protected].

pnpm install
pnpm run dev

The dev script expands to nx run-many -t dev tauri:dev, so you get the front-end dev server and the Tauri shell together. If you only want the web build and not the desktop wrapper, the build:no-tauri script runs nx run-many -t build on its own.

pnpm run build:no-tauri

Once the app is open, the README's workflow is mouse-driven: drag to create a node, drag between nodes to connect them, drag a node to reposition it. To get a DAG specifically, place your nodes first and then add edges in one direction only, since the README lists DAG as a supported diagram type but does not describe an automatic cycle check that would stop you from drawing one. There is no documented keyboard shortcut list and no documented command-line flag for creating a graph from a file.

The gaps the README leaves open

The most consequential omission is licensing. The README carries a badge reading MIT and GPL 3.0, but the top-level repository entries do not include a LICENSE file, and the metadata records the licence as unknown. A dual MIT and GPL badge is a real signal, but it is not the same as a licence file you can read. If you intend to embed Project Graph in a commercial product, or to fork it, that distinction matters and you should resolve it at the source before you build on it. This is not legal advice; it is a statement that the repository as listed does not settle the question.

The second gap is the absence of any documented automation surface. The package.json declares a CLI package, @graphif/project-graph-cli, and scripts named benchmark:cli:cold-start and test:cli:desktop, which implies a command-line entry point exists. But the README documents no CLI flags, no file format, and no import or export path. If your workflow needs to generate a graph from a script or validate one in CI, the README does not tell you how, and you would be reading source to find out.

The third gap is rollback and version compatibility. The README promises autosave and backup but does not document how to restore from a backup, how far back backups go, or whether a document written by v4.2.3 opens in v4.2.4. For a tool whose selling point is not losing your work, that is the documentation you would want first.

Where Project Graph is the wrong tool

If the diagram has to be produced by a machine on every commit, Project Graph is the wrong layer. It is a desktop application with a GUI editing model; nothing in the README suggests a headless mode, a stable file schema, or a documented API for generating diagrams programmatically. The repository topics mention graph-algorithms, which suggests graph traversal code lives in the codebase, but the README does not expose it as a user-facing capability.

It is also the wrong tool if your team needs real-time multiplayer editing. The README describes a local desktop app with automatic saving and backup; there is no mention of a server, accounts, sharing links or concurrent editing. Collaboration, if it happens, goes through the exported document, not through a live session.

And it is the wrong tool if you need a diagram format that other tools can read. The README does not name an export format. A tool that cannot tell you what it writes to disk is hard to put in a pipeline where a second program has to consume the output.

How it differs from Mermaid and from a general whiteboard

Mermaid takes the opposite approach to the same problem. You write a text description of the graph in a Markdown code block, and a renderer draws it. That makes Mermaid ideal for version control, code review and documentation that has to stay in sync with source, and it makes it painful when you are still deciding what the graph should be, because every rearrangement is an edit to text. Project Graph inverts this: the graph is the artifact and the text is absent. You get direct manipulation, undo and redo, and a canvas that suits a brainstorming session where the structure is not yet known. You lose diffability, and you lose the ability to generate the diagram from a script.

Against a general-purpose whiteboard, the difference is scope. A whiteboard gives you freeform shapes and sticky notes; Project Graph gives you nodes and edges as first-class objects with a stated set of supported graph types. The README also lists multi-language support including a full Chinese interface, which matters if your team works in Chinese and your whiteboard tool's terminology does not translate well. The trade-off is that a whiteboard will draw anything, while Project Graph is opinionated about what a diagram is.

Maintenance, releases and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-22. The release list shows v4.2.4 on 2026-09-06, v4.2.3 on 2026-08-10, and a nightly build published on 2026-09-22. A nightly channel existing alongside tagged releases is a useful signal for adopters: it means unreleased work is being built continuously, and it also means you should not treat nightly as a stable target. The gap between v4.2.3 and v4.2.4 is roughly four weeks, which is a patch cadence rather than a long-term-support cadence.

Upgrade cost is where the missing documentation bites. The README does not describe a migration path between minor versions, and it does not state whether documents are forward or backward compatible. The autosave and backup feature reduces the risk of losing work during an upgrade, but it does not reduce the risk of a format change, because the README never describes the format. Before you upgrade a document you care about, open a copy in the new version and check that the graph still renders as you left it. On the build side, the Node >= 26.0.0 engine requirement is aggressive; a contributor or CI runner on an older LTS will fail at install time rather than at build time, which at least makes the failure obvious.

Editorial conclusion

Adopt Project Graph if you want a local, cross-platform canvas for brainstorming, curriculum maps or module dependency diagrams, and you are comfortable installing a signed desktop build rather than running a web service. Do not adopt it if you need a documented scripting API, a headless CI pipeline, or a licence you can confirm before shipping it inside a commercial product: the README shows an MIT and GPL 3.0 badge but the repository carries no LICENSE file in its top-level entries, so confirm the terms at graphif.dev before you redistribute anything. Before committing a team to it, verify two things yourself: whether a v4.2.3 document opens cleanly in v4.2.4, and whether the autosave backup directory is where you expect it to be on your platform.

Frequently asked questions

Official sources

1. graphif/project-graph on GitHub
2. Issues
3. Project website
4. README
5. Releases