# Archify Component Type Variants: The Complete Guide to Seven Visual System Categories

> Discover the seven Archify component type variants frontend backend database cloud security messagebus and external. These visual system categories adapt to dark and light modes automatically.

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

---

**Archify provides seven distinct component type variants (`frontend`, `backend`, `database`, `cloud`, `security`, `messagebus`, `external`) that automatically adapt their color schemes between dark and light modes.**

The Archify visualization framework uses these seven standardized types to categorize and style system architecture components. Each variant carries coordinated dark- and light-mode color palettes that toggle together via the global theme switch. Understanding these variants is essential for creating consistent, readable architecture diagrams in any Archify project.

## The Seven Archify Component Type Variants

Archify defines exactly seven component type variants. Each serves a specific architectural purpose and receives distinct visual treatment in generated diagrams.

### 1. Frontend Components

The **frontend** variant represents UI-oriented services and applications—anything that renders directly in a browser or native client.

Components using this type receive styling via the `--frontend-fill` CSS custom property defined in the visual evolution prototype.

```json
{
  "id": "ui-dashboard",
  "label": "Dashboard UI",
  "type": "frontend"
}

```

### 2. Backend Components

The **backend** variant covers server-side logic and processing services. Use this for APIs, business logic layers, and microservices that don't serve direct user interfaces.

Styling is controlled by `--backend-fill` in the theme system.

```json
{
  "id": "order-service",
  "label": "Order Processing Service",
  "type": "backend"
}

```

### 3. Database Components

The **database** variant marks persistent storage layers. This includes relational databases, document stores, caches, and any system responsible for data durability.

The associated CSS variable is `--database-fill`.

```json
{
  "id": "user-db",
  "label": "User Database",
  "type": "database"
}

```

### 4. Cloud Components

The **cloud** variant identifies cloud-native resources: storage buckets, serverless functions, managed queues, and vendor-specific infrastructure services that aren't traditional servers.

This type uses `--cloud-fill` for its visual representation.

```json
{
  "id": "storage-bucket",
  "label": "Asset Storage Bucket",
  "type": "cloud"
}

```

### 5. Security Components

The **security** variant covers authentication, authorization, and other security mechanisms—identity providers, API gateways with auth rules, secrets managers, and policy enforcement points.

The `--security-fill` property drives its styling.

```json
{
  "id": "auth-gateway",
  "label": "Authentication Gateway",
  "type": "security"
}

```

### 6. Messagebus Components

The **messagebus** variant represents event-driven or messaging infrastructure. Use this for event buses, message queues, pub/sub systems, and streaming platforms.

Visual treatment comes from `--messagebus-fill`.

```json
{
  "id": "event-bus",
  "label": "Event Bus",
  "type": "messagebus"
}

```

### 7. External Components

The **external** variant marks third-party or external services that interact with your architecture but live outside your direct control—payment processors, external APIs, SaaS integrations, and partner systems.

This type applies `--external-fill` for consistent visual distinction from internal components.

```json
{
  "id": "payment-gateway",
  "label": "External Payment Provider",
  "type": "external"
}

```

## How Component Type Variants Work in the Source Code

The Archify component type system is implemented across several key files in the `tt-a1i/archify` repository.

### Documentation Reference

According to [`docs/index.html`](https://github.com/tt-a1i/archify/blob/main/docs/index.html), the framework explicitly documents "Seven component types" with synchronized theme behavior. This serves as the authoritative reference for which types are available and how they respond to mode switching.

### Visual Styling Implementation

The actual color definitions live in [`experiments/visual-evolution/prototype.html`](https://github.com/tt-a1i/archify/blob/main/experiments/visual-evolution/prototype.html). This file contains the complete set of CSS custom properties:

- `--frontend-fill`
- `--backend-fill`
- `--database-fill`
- `--cloud-fill`
- `--security-fill`
- `--messagebus-fill`
- `--external-fill`

Each property maintains two values that swap when the theme toggle fires, ensuring consistent visual hierarchy across both modes.

### Validation and Testing

The `archify/test/*.test.mjs` files contain test suites that validate rendering of all seven component-type variants in various scenarios. These tests ensure that every declared type receives correct styling and that no invalid types slip through validation.

## Declaring Component Types in Architecture Files

Component types are specified in `*.architecture.json` files within the `components` array. The `type` field accepts only the seven valid strings—any other value will fail validation or fall back to a default appearance.

Example structure from files under `examples/`:

```json
{
  "components": [
    {
      "id": "web-client",
      "label": "Web Application",
      "type": "frontend"
    },
    {
      "id": "api-layer",
      "label": "REST API",
      "type": "backend"
    },
    {
      "id": "main-postgres",
      "label": "Primary Database",
      "type": "database"
    }
  ]
}

```

## Summary

- Archify provides **seven component type variants**: `frontend`, `backend`, `database`, `cloud`, `security`, `messagebus`, `external`
- Each variant has **coordinated dark- and light-mode color palettes** that toggle together via the theme switch
- Type styling is defined via CSS custom properties in [`experiments/visual-evolution/prototype.html`](https://github.com/tt-a1i/archify/blob/main/experiments/visual-evolution/prototype.html)
- Valid types are enforced by test suites in `archify/test/*.test.mjs`
- Component types are declared using the `type` field in `*.architecture.json` files

## Frequently Asked Questions

### What happens if I use an invalid component type in Archify?

Archify validates component types against the seven allowed variants. Using an unrecognised type will likely result in a validation error during diagram generation or cause the component to render without proper styling. The test suites in `archify/test/*.test.mjs` enforce this constraint.

### Can I extend Archify with custom component types?

The current Archify implementation as documented in [`docs/index.html`](https://github.com/tt-a1i/archify/blob/main/docs/index.html) specifies exactly seven component types. The CSS variable definitions in [`prototype.html`](https://github.com/tt-a1i/archify/blob/main/prototype.html) are hardcoded for these variants. Custom types would require modification of the source styling system and validation logic.

### How do I switch between dark and light mode for component colors?

The theme switch toggles all component color palettes simultaneously. You don't configure this per-type—each CSS custom property (`--frontend-fill`, `--backend-fill`, etc.) contains both color values and responds automatically to the global theme state.

### Where can I see example architecture files using these types?

The `examples/` directory in the repository contains `*.architecture.json` files demonstrating realistic component configurations. These files show how the seven type variants are applied to represent complete system architectures.