# Archify Component Types Explained: A Complete Guide to Schema-Driven Architecture Diagrams

> Discover Archify component types, from frontend to database, essential for creating schema-driven architecture diagrams. Learn how types define validation, rendering, and styling.

- Repository: [tt-a1i/archify](https://github.com/tt-a1i/archify)
- Tags: deep-dive
- Published: 2026-09-13

---

**Archify component types are a strict enumeration of seven categories—frontend, backend, database, cloud, security, messagebus, and external—defined in [`archify/schemas/common.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/common.schema.json) that determine how each node is validated, rendered, and styled in architecture diagrams.**

Archify is an open-source diagramming tool in the `tt-a1i/archify` repository that enforces schema-driven architecture documentation through strict JSON schemas. Understanding the seven Archify component types is essential for authoring valid diagrams that render correctly with distinct icons, color palettes, and layout heuristics derived from the core schema.

## The Canonical Component Type Enumeration

The authoritative list of allowed values resides in [`archify/schemas/common.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/common.schema.json) at line 39, where the `componentType` enum restricts every component to one of seven specific strings. This enumeration is mirrored verbatim in the authoring contract at [`archify/references/authoring-contract.md`](https://github.com/tt-a1i/archify/blob/main/archify/references/authoring-contract.md) (line 9), ensuring consistency between validation logic and documentation standards.

### Frontend

Components with the `frontend` type represent UI-level services that users interact with directly, such as web interfaces or mobile applications. The renderer assigns these nodes a window-style icon and positions them to indicate user-facing entry points in the architecture.

### Backend

The `backend` type identifies application-level services implementing core business logic, including API servers and authentication services. These components typically sit between frontend and data layers, rendered with bracket-style icons to denote processing capabilities.

### Database

Use `database` for persistent storage systems like PostgreSQL or MongoDB that maintain state. These nodes receive cylinder icons and are visually grouped to emphasize data persistence responsibilities within the system.

### Cloud

The `cloud` type covers managed cloud resources that are not pure storage, such as Redis caches or AWS S3 buckets. Unlike databases, these components represent infrastructure services and are rendered with cloud-style icons to distinguish them from persistent data stores.

### Security

Security components enforce guardrails through firewalls, IAM policies, or secret managers like Vault. Tagged with `security`, these nodes display shield icons and often sit at boundary points to indicate protective barriers.

### Messagebus

Asynchronous messaging and streaming platforms such as Kafka or RabbitMQ use the `messagebus` type. These components feature transit rail icons to represent event-driven communication patterns between services.

### External

Anything outside the system's trust boundary—including third-party APIs, payment gateways, and OAuth providers—uses the `external` type. These portal-style icons visually separate external dependencies from internal infrastructure.

## Validation and Rendering Logic

When an architecture diagram is authored, each component object must include a `type` field matching one of the seven enumeration values, as enforced by [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json). The renderer consumes this field to drive legend generation, color palettes, and specialized layout heuristics without requiring manual legend configuration in the `meta` object.

The type system also enables profile-based validation rules. According to the authoring contract at lines 88-94, the optional **deployment-ownership** profile restricts ownership tags, regions, and security groups to non-`external` components only, as external resources exist outside the system's administrative control.

## Practical JSON Implementation

The following minimal Archify JSON IR demonstrates proper usage of all seven component types. Save this as [`sample.architecture.json`](https://github.com/tt-a1i/archify/blob/main/sample.architecture.json) and render it using the CLI:

```json
{
  "schema_version": 1,
  "meta": { "title": "Sample Architecture" },
  "components": [
    { "id": "frontend", "type": "frontend", "label": "Web UI" },
    { "id": "backend",  "type": "backend",  "label": "API Server" },
    { "id": "db",       "type": "database", "label": "PostgreSQL" },
    { "id": "cache",    "type": "cloud",    "label": "Redis Cache" },
    { "id": "msg",      "type": "messagebus", "label": "Kafka" },
    { "id": "sec",      "type": "security", "label": "WAF" },
    { "id": "ext",      "type": "external", "label": "Payment Gateway" }
  ],
  "connections": [
    { "source": "frontend", "target": "backend" },
    { "source": "backend",  "target": "db" },
    { "source": "backend",  "target": "cache" },
    { "source": "backend",  "target": "msg" },
    { "source": "backend",  "target": "sec" },
    { "source": "backend",  "target": "ext" }
  ]
}

```

Execute the rendering command:

```bash
node archify/bin/archify.mjs deliver architecture sample.architecture.json out.html

```

This produces a diagram where each component renders with its dedicated icon: frontend uses a window symbol, backend uses brackets, database uses a cylinder, cloud uses a cloud shape, security uses a shield, messagebus uses transit rails, and external uses a portal icon.

## Summary

- Archify component types are strictly defined in [`archify/schemas/common.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/common.schema.json) as a seven-value enumeration
- Valid types are: **frontend**, **backend**, **database**, **cloud**, **security**, **messagebus**, and **external**
- Each type drives specific rendering icons, color schemes, and layout positioning in generated diagrams
- The `type` field in component objects is mandatory and validated against [`archify/schemas/architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json)
- Deployment-ownership profiles exclude external components from requiring ownership metadata

## Frequently Asked Questions

### What are the seven valid Archify component types?

The seven valid Archify component types are **frontend**, **backend**, **database**, **cloud**, **security**, **messagebus**, and **external**, as defined in [`archify/schemas/common.schema.json`](https://github.com/tt-a1i/archify/blob/main/archify/schemas/common.schema.json) and documented in the authoring contract.

### How do I specify a component type in an Archify JSON file?

Set the `type` field inside each component object to one of the seven enumeration strings. For example: `"type": "database"` for PostgreSQL instances or `"type": "external"` for third-party APIs.

### What is the difference between cloud and database types in Archify?

**Database** components represent persistent state storage systems like PostgreSQL or MongoDB, while **cloud** components represent managed infrastructure services that are not pure storage, such as Redis caches or AWS S3 buckets, each rendering with distinct visual icons.

### Can external components have deployment ownership in Archify?

No. According to the authoring contract at [`archify/references/authoring-contract.md`](https://github.com/tt-a1i/archify/blob/main/archify/references/authoring-contract.md) lines 88-94, the optional deployment-ownership profile specifically excludes **external** components from requiring ownership tags, regions, or security groups because they exist outside the system's trust boundary.