draw.io

draw.io (also known as diagrams.net) is a browser‑based diagramming and whiteboarding engine that runs entirely on the client side, with optional server backends for persistence. From a developer’s perspective it is a self‑contained JavaScript application that bundles a highly optimized, minified client bundle (draw.io.min.js) together with a lightweight servlet layer for file storage and integration hooks. The core functionality is delivered via the mxGraph engine, a mature JavaScript library for graph and diagram rendering that has been in use since the early 2000s. The application exposes a rich set of programmatic APIs—such as mxEditor, mxGraphModel, and custom shape registries—that allow developers to instantiate, manipulate, and serialize diagrams without touching the UI directly.

Architecture

• Frontend: Pure JavaScript/HTML5, heavily minified and bundled. The UI is built around the mxGraph core, with custom panels, dialogs, and a responsive toolbar. The code is licensed under Apache 2.0, ensuring permissive reuse while keeping the source closed to maintain commercial control.
• Backend (optional): A Java servlet stack packaged as a WAR (drawio.war) that serves static assets and provides REST endpoints for file operations (save, load, export). The backend is minimal, using standard Java EE containers such as Tomcat or Jetty; no heavy database layer is required unless the developer opts for a custom persistence solution.
• Deployment: The application can be run as a static site (GitHub Pages, Netlify) or via Docker (jgraph/docker-drawio). The Docker image bundles the WAR with a lightweight Tomcat instance, exposing /draw.io as the entry point. For high‑availability setups, multiple instances can be load‑balanced behind a reverse proxy (NGINX/Traefik) with sticky sessions if the same user must hit a single backend for stateful operations.

Core Capabilities

• Diagram API: Programmatic access to graph models (mxGraphModel), shapes, connectors, and styles. Scripts can create or modify diagrams on the fly, enabling use cases such as auto‑generation of UML from code metadata.
• Import/Export: Native support for XML, SVG, PNG, JPEG, and the proprietary .drawio format. The API exposes mxCodec for custom serialization hooks.
• File Storage: REST endpoints (/save, /load) that accept multipart form data. Developers can swap out the default servlet implementation for a cloud‑based storage layer (S3, Azure Blob) by extending the org.jgraph.drawing.servlet classes.
• Extensions: The application ships with a plugin architecture based on JavaScript modules. Third‑party developers can register new shape libraries, custom toolbar buttons, or event listeners via the mxGraph extension points. While the source is closed, the API surface is well documented in the docs/ folder of the repository.

Deployment & Infrastructure

Self‑hosting is straightforward: clone the repo, build the WAR with Maven (mvn clean package), and deploy to any servlet container. Docker simplifies this further—pull the official image, map a volume for persistent storage (/opt/drawio/data), and expose port 8080. The application is stateless beyond file operations, making horizontal scaling trivial: a cluster of containers behind a load balancer can serve millions of concurrent users without shared state. For environments with strict compliance needs, the closed‑source license ensures no accidental exposure of proprietary code.

Integration & Extensibility

• Webhooks: The backend can be extended to emit events on file changes, allowing CI/CD pipelines or external dashboards to react in real time.
• Authentication: Although the core app is unauthenticated, developers can wrap the servlet layer with OAuth2 or SAML filters to integrate into corporate identity providers.
• Custom Shape Libraries: Users can import JSON shape definitions, and developers can expose domain‑specific icons (e.g., Kubernetes glyphs) via the mxShapeRegistry.
• Embedding: The editor can be embedded in other web applications by loading index.html inside an iframe and communicating via the postMessage API, enabling “diagram as a service” scenarios.

Developer Experience

The project’s documentation is concise but covers the essential build and deployment steps. The API surface is stable, with extensive examples in the samples/ directory (though not exhaustive). Community support is modest; issues are triaged on GitHub, and the Docker repository hosts a helpful README. The closed‑source nature means contributors cannot submit pull requests, but the clear licensing and modular architecture allow developers to build extensions without touching core code.

Use Cases

• Enterprise Documentation: Self‑hosted instances can store proprietary architecture diagrams, ensuring data never leaves the internal network.
• CI/CD Visualization: Generate deployment flowcharts from YAML files automatically and publish them to a shared portal.
• Education Platforms: Embed the editor in LMS systems for interactive diagramming assignments while keeping control over user data.
• Compliance‑Sensitive Projects: Deploy on private clouds where open‑source alternatives with unknown code bases are unacceptable.

Advantages

• Performance: The client bundle is heavily optimized; rendering large graphs remains smooth due to mxGraph’s incremental repainting.
• Flexibility: Java backend can be swapped for any servlet‑compatible server; Docker images make scaling trivial.
• Licensing: Apache 2.0 on the minified code ensures no copyleft obligations, while the proprietary license protects