# Archify Semantic Component Types for Architecture Diagrams: A Complete Guide

> Discover Archify's seven semantic component types frontend, backend, database, cloud, security, messagebus, and external. Standardize your architecture diagrams with this comprehensive guide.

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

---

**Archify defines seven semantic component types—frontend, backend, database, cloud, security, messagebus, and external—in [`common.schema.json`](https://github.com/tt-a1i/archify/blob/main/common.schema.json) to standardize how components are categorized in Architecture diagrams.**

Archify uses a strict schema system to ensure consistency across architecture diagrams. The **semantic component types** establish a shared vocabulary for describing system components, defined in the shared schema and enforced at validation time according to the tt-a1i/archify source code.

## The Seven Semantic Component Types

Archify recognizes exactly seven distinct semantic categories for architecture components. Each type serves a specific infrastructural role and carries semantic meaning for visualization and documentation purposes.

### frontend

UI-side or client-facing services including web applications, mobile front-ends, and user interfaces.

### backend

Server-side business logic, APIs, and microservices that process application requests.

### database

Persistent storage systems encompassing SQL databases, NoSQL stores, and data warehouses.

### cloud

Cloud-native resources such as servers, containers, and managed services from providers like AWS, Azure, or GCP.

### security

Security-related elements including firewalls, IAM systems, and authentication gateways.

### messagebus

Messaging or event-bus infrastructure such as Kafka, RabbitMQ, or other asynchronous communication systems.

### external

External third-party services or APIs that fall outside the diagram's organizational scope.

## Schema Definition and Source Files

The semantic component types are enforced through JSON Schema validation. The canonical definition resides in the shared schema file that architecture diagrams reference.

### common.schema.json

The [[`common.schema.json`](https://github.com/tt-a1i/archify/blob/main/common.schema.json)](https://github.com/tt-a1i/archify/blob/main/archify/schemas/common.schema.json) file contains the `componentType` enumeration that lists these seven values (lines 39-41). This central definition ensures consistency across all diagram types that reference the common schema.

### architecture.schema.json

The [[`architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/architecture.schema.json)](https://github.com/tt-a1i/archify/blob/main/archify/schemas/architecture.schema.json) imports the shared definitions and applies the `componentType` constraint to the `type` field within component objects. This inheritance pattern ensures that all Architecture diagram components must use one of the seven predefined semantic types.

## Practical Implementation

When constructing an Architecture diagram, each component requires an `id`, `type`, and `label` field. The `type` field must contain exactly one of the seven semantic component types.

```json
{
  "schema_version": 1,
  "diagram_type": "architecture",
  "meta": { "title": "Sample Component Types" },
  "components": [
    { "id": "ui",    "type": "frontend",   "label": "Web UI" },
    { "id": "api",   "type": "backend",    "label": "API Service" },
    { "id": "db",    "type": "database",   "label": "PostgreSQL" },
    { "id": "cloud", "type": "cloud",      "label": "AWS EC2" },
    { "id": "sec",   "type": "security",   "label": "Auth Gateway" },
    { "id": "bus",   "type": "messagebus", "label": "Kafka Bus" },
    { "id": "ext",   "type": "external",   "label": "Stripe API" }
  ],
  "connections": [
    { "from": "ui",  "to": "api", "variant": "emphasis" },
    { "from": "api", "to": "db",  "variant": "default" }
  ]
}

```

Save this structure to a file with the [`.architecture.json`](https://github.com/tt-a1i/archify/blob/main/.architecture.json) extension (e.g., [`my-diagram.architecture.json`](https://github.com/tt-a1i/archify/blob/main/my-diagram.architecture.json)). The Archify CLI validates the `type` field against the `componentType` enumeration during rendering, throwing schema validation errors for undefined types.

## Summary

- Archify provides exactly **seven semantic component types** for Architecture diagrams: `frontend`, `backend`, `database`, `cloud`, `security`, `messagebus`, and `external`.
- Type definitions are centralized in **[`common.schema.json`](https://github.com/tt-a1i/archify/blob/main/common.schema.json)** (lines 39-41) and referenced by **[`architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/architecture.schema.json)**.
- Each component requires the `id`, `type`, and `label` fields, with `type` restricted to the predefined enumeration.
- The schema validation ensures diagram consistency and enables semantic-aware rendering across the Archify toolchain.

## Frequently Asked Questions

### What are the valid semantic component types in Archify?

The valid semantic component types are `frontend`, `backend`, `database`, `cloud`, `security`, `messagebus`, and `external`. These seven values are enumerated in [`common.schema.json`](https://github.com/tt-a1i/archify/blob/main/common.schema.json) and represent the complete set of allowed types for Architecture diagram components.

### Can I use custom component types outside the defined enum?

No. The [`architecture.schema.json`](https://github.com/tt-a1i/archify/blob/main/architecture.schema.json) strictly validates the `type` field against the `componentType` enumeration defined in [`common.schema.json`](https://github.com/tt-a1i/archify/blob/main/common.schema.json). Attempting to use undefined types will result in schema validation errors when processing diagrams through the Archify CLI or web viewer.

### How does Archify validate component types?

Archify uses JSON Schema validation to enforce component types. When you run the Archify CLI against an [`.architecture.json`](https://github.com/tt-a1i/archify/blob/main/.architecture.json) file, it checks that every component's `type` field matches one of the seven allowed values in the `componentType` enumeration. This validation occurs before rendering to ensure semantic consistency.

### Where can I see real-world examples of these component types?

The repository includes an example file at [[`examples/archify-repo.architecture.json`](https://github.com/tt-a1i/archify/blob/main/examples/archify-repo.architecture.json)](https://github.com/tt-a1i/archify/blob/main/examples/archify-repo.architecture.json) that demonstrates various semantic component types in a production-quality architecture diagram.