Archify Supported Component Types for Architecture Diagrams: Complete Reference

Archify supports seven component types for architecture diagrams: frontend, backend, database, cloud, security, messagebus, and external.

These types are defined in the archify/schemas/common.schema.json schema and enforced when diagram_type is set to "architecture". Each type controls visual styling—including fill color, stroke color, and iconography—to maintain consistency across generated diagrams.

Component Type Reference Table

The following types are available in the $defs/componentType enumeration:

Component type	Typical role
frontend	UI-layer services, browsers, mobile applications
backend	Application servers and business-logic services
database	Persistent storage systems (SQL, NoSQL, vector stores)
cloud	Cloud-native services, SaaS offerings, IaaS resources
security	OAuth providers, firewalls, encryption gateways
messagebus	Event buses and messaging systems (Kafka, RabbitMQ)
external	Third-party APIs, external users, systems outside the boundary

How Component Types Work in Practice

In archify/schemas/architecture.schema.json, every component in the components array must declare a type field. The value is validated against the enumeration in archify/schemas/common.schema.json under $defs/componentType.

Basic Component Structure

{
  "id": "auth",
  "type": "security",
  "label": "Auth Provider",
  "sublabel": "OAuth 2.0",
  "tag": "JWT + PKCE"
}

Each field serves a specific purpose:

• id — unique identifier for referencing in connections
• type — determines visual styling and semantic category
• label — primary display name in the diagram
• sublabel — secondary descriptive text (optional)
• tag — additional metadata badge (optional)

Complete Example: All Seven Component Types

This example from the tt-a1i/archify repository demonstrates proper usage of every supported type:

{
  "schema_version": 1,
  "diagram_type": "architecture",
  "meta": { "title": "Demo Architecture" },
  "components": [
    { "id": "ui",    "type": "frontend",   "label": "Web UI" },
    { "id": "svc",   "type": "backend",    "label": "API Service" },
    { "id": "db",    "type": "database",   "label": "PostgreSQL" },
    { "id": "cloud", "type": "cloud",      "label": "AWS S3" },
    { "id": "auth",  "type": "security",   "label": "Auth Provider" },
    { "id": "bus",   "type": "messagebus", "label": "Kafka Bus" },
    { "id": "ext",   "type": "external",   "label": "Third-Party API" }
  ],
  "connections": [
    { "from": "ui",   "to": "svc" },
    { "from": "svc",  "to": "db" },
    { "from": "svc",  "to": "cloud" },
    { "from": "svc",  "to": "auth" },
    { "from": "svc",  "to": "bus" },
    { "from": "svc",  "to": "ext" }
  ]
}

Real-World Pattern: RAG Pipeline

From examples/rag-pipeline.architecture.json in the source repository, this excerpt shows how external and database types model a retrieval-augmented generation system:

{
  "components": [
    { "id": "user",      "type": "external",   "label": "User",      "sublabel": "Chat / API" },
    { "id": "vectordb",  "type": "database",   "label": "Vector Store", "sublabel": "Milvus" },
    { "id": "sources",   "type": "external",   "label": "Documents", "sublabel": "PDF / Web / DB" }
  ],
  "connections": [
    { "from": "user",    "to": "vectordb" },
    { "from": "sources", "to": "vectordb" }
  ]
}

Notice the database type used for the vector store (Milvus)—a specialized NoSQL database—demonstrating that the type covers all persistence layers regardless of implementation.

Visual Styling Behavior

The type field directly controls renderer output. As implemented in tt-a1i/archify, each type maps to:

1. Fill color — semantic coloring (e.g., security types use accent colors)
2. Stroke color — boundary highlighting for grouping
3. Iconography — recognizable symbols for quick visual parsing

This ensures architecture diagrams remain readable without custom styling configuration.

Schema Enforcement Locations

The supported component types are defined and validated in two key files:

• archify/schemas/common.schema.json — contains the canonical $defs/componentType enumeration
• archify/schemas/architecture.schema.json — references this definition for the diagram_type: "architecture" schema

Attempts to use an undefined type will fail validation against these schemas.

Summary

• Archify provides seven fixed component types for architecture diagrams: frontend, backend, database, cloud, security, messagebus, and external
• Types are defined in archify/schemas/common.schema.json and enforced via archify/schemas/architecture.schema.json
• The type field controls visual rendering: fill color, stroke color, and icons
• All seven types can appear in a single diagram with connections between any components
• Types are semantic categories—database covers SQL, NoSQL, and vector stores; external covers any out-of-boundary element

Frequently Asked Questions

What happens if I use an unsupported component type?

Schema validation will fail. The architecture.schema.json strictly references the $defs/componentType enumeration from common.schema.json, rejecting any type value not in the approved list of seven.

Can I extend Archify with custom component types?

No. The enumeration in archify/schemas/common.schema.json is fixed. Custom styling requires using the existing semantic types and distinguishing components via label, sublabel, or tag fields.

How do I represent a microservices mesh without cluttering the diagram?

Use the messagebus type for the service mesh infrastructure, then connect individual backend components to it. This abstracts the mesh complexity while maintaining accurate topology.

Is there a difference between cloud and external types?

Yes. The cloud type represents cloud-native resources within your operational boundary (AWS S3, managed databases), while external marks elements completely outside your system (third-party APIs, end users, partner systems).

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}