# Archify Supported Component Types for Architecture Diagrams: Complete Reference

> Discover Archify supported component types for architecture diagrams: frontend, backend, database, cloud, security, messagebus, and external. Build better diagrams now.

- Repository: [tt-a1i/archify](https://github.com/tt-a1i/archify)
- Tags: api-reference
- Published: 2026-09-06

---

**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`](https://github.com/tt-a1i/archify/blob/main/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`](https://github.com/tt-a1i/archify/blob/main/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`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/common.schema.json) under `$defs/componentType`.

### Basic Component Structure

```json
{
  "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:

```json
{
  "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`](https://github.com/tt-a1i/archify/blob/main/examples/rag-pipeline.architecture.json) in the source repository, this excerpt shows how `external` and `database` types model a retrieval-augmented generation system:

```json
{
  "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`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/common.schema.json)** — contains the canonical `$defs/componentType` enumeration
- **[`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/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`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/common.schema.json) and enforced via [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/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`](https://github.com/tt-a1i/archify/blob/main/architecture.schema.json) strictly references the `$defs/componentType` enumeration from [`common.schema.json`](https://github.com/tt-a1i/archify/blob/main/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`](https://github.com/tt-a1i/archify/blob/main/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).