jeremylongshore

clay-architecture-variants

@jeremylongshore/clay-architecture-variants
jeremylongshore
1,004
123 forks
Updated 1/18/2026
View on GitHub

Choose and implement Clay validated architecture blueprints for different scales. Use when designing new Clay integrations, choosing between monolith/service/microservice architectures, or planning migration paths for Clay applications. Trigger with phrases like "clay architecture", "clay blueprint", "how to structure clay", "clay project layout", "clay microservice".

Installation

$skills install @jeremylongshore/clay-architecture-variants
Claude Code
Cursor
Copilot
Codex
Antigravity

Details

Pathplugins/saas-packs/clay-pack/skills/clay-architecture-variants/SKILL.md
Branchmain
Scoped Name@jeremylongshore/clay-architecture-variants

Usage

After installing, this skill will be available to your AI coding assistant.

Verify installation:

skills list

Skill Instructions


name: clay-architecture-variants description: | Choose and implement Clay validated architecture blueprints for different scales. Use when designing new Clay integrations, choosing between monolith/service/microservice architectures, or planning migration paths for Clay applications. Trigger with phrases like "clay architecture", "clay blueprint", "how to structure clay", "clay project layout", "clay microservice". allowed-tools: Read, Grep version: 1.0.0 license: MIT author: Jeremy Longshore jeremy@intentsolutions.io

Clay Architecture Variants

Overview

Three validated architecture blueprints for Clay integrations.

Prerequisites

  • Understanding of team size and DAU requirements
  • Knowledge of deployment infrastructure
  • Clear SLA requirements
  • Growth projections available

Variant A: Monolith (Simple)

Best for: MVPs, small teams, < 10K daily active users

my-app/
├── src/
│   ├── clay/
│   │   ├── client.ts          # Singleton client
│   │   ├── types.ts           # Types
│   │   └── middleware.ts      # Express middleware
│   ├── routes/
│   │   └── api/
│   │       └── clay.ts    # API routes
│   └── index.ts
├── tests/
│   └── clay.test.ts
└── package.json

Key Characteristics

  • Single deployment unit
  • Synchronous Clay calls in request path
  • In-memory caching
  • Simple error handling

Code Pattern

// Direct integration in route handler
app.post('/api/create', async (req, res) => {
  try {
    const result = await clayClient.create(req.body);
    res.json(result);
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

Variant B: Service Layer (Moderate)

Best for: Growing startups, 10K-100K DAU, multiple integrations

my-app/
├── src/
│   ├── services/
│   │   ├── clay/
│   │   │   ├── client.ts      # Client wrapper
│   │   │   ├── service.ts     # Business logic
│   │   │   ├── repository.ts  # Data access
│   │   │   └── types.ts
│   │   └── index.ts           # Service exports
│   ├── controllers/
│   │   └── clay.ts
│   ├── routes/
│   ├── middleware/
│   ├── queue/
│   │   └── clay-processor.ts  # Async processing
│   └── index.ts
├── config/
│   └── clay/
└── package.json

Key Characteristics

  • Separation of concerns
  • Background job processing
  • Redis caching
  • Circuit breaker pattern
  • Structured error handling

Code Pattern

// Service layer abstraction
class ClayService {
  constructor(
    private client: ClayClient,
    private cache: CacheService,
    private queue: QueueService
  ) {}

  async createResource(data: CreateInput): Promise<Resource> {
    // Business logic before API call
    const validated = this.validate(data);

    // Check cache
    const cached = await this.cache.get(cacheKey);
    if (cached) return cached;

    // API call with retry
    const result = await this.withRetry(() =>
      this.client.create(validated)
    );

    // Cache result
    await this.cache.set(cacheKey, result, 300);

    // Async follow-up
    await this.queue.enqueue('clay.post-create', result);

    return result;
  }
}

Variant C: Microservice (Complex)

Best for: Enterprise, 100K+ DAU, strict SLAs

clay-service/              # Dedicated microservice
├── src/
│   ├── api/
│   │   ├── grpc/
│   │   │   └── clay.proto
│   │   └── rest/
│   │       └── routes.ts
│   ├── domain/
│   │   ├── entities/
│   │   ├── events/
│   │   └── services/
│   ├── infrastructure/
│   │   ├── clay/
│   │   │   ├── client.ts
│   │   │   ├── mapper.ts
│   │   │   └── circuit-breaker.ts
│   │   ├── cache/
│   │   ├── queue/
│   │   └── database/
│   └── index.ts
├── config/
├── k8s/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── hpa.yaml
└── package.json

other-services/
├── order-service/       # Calls clay-service
├── payment-service/
└── notification-service/

Key Characteristics

  • Dedicated Clay microservice
  • gRPC for internal communication
  • Event-driven architecture
  • Database per service
  • Kubernetes autoscaling
  • Distributed tracing
  • Circuit breaker per service

Code Pattern

// Event-driven with domain isolation
class ClayAggregate {
  private events: DomainEvent[] = [];

  process(command: ClayCommand): void {
    // Domain logic
    const result = this.execute(command);

    // Emit domain event
    this.events.push(new ClayProcessedEvent(result));
  }

  getUncommittedEvents(): DomainEvent[] {
    return [...this.events];
  }
}

// Event handler
@EventHandler(ClayProcessedEvent)
class ClayEventHandler {
  async handle(event: ClayProcessedEvent): Promise<void> {
    // Saga orchestration
    await this.sagaOrchestrator.continue(event);
  }
}

Decision Matrix

FactorMonolithService LayerMicroservice
Team Size1-55-2020+
DAU< 10K10K-100K100K+
Deployment FrequencyWeeklyDailyContinuous
Failure IsolationNonePartialFull
Operational ComplexityLowMediumHigh
Time to MarketFastestModerateSlowest

Migration Path

Monolith → Service Layer:
1. Extract Clay code to service/
2. Add caching layer
3. Add background processing

Service Layer → Microservice:
1. Create dedicated clay-service repo
2. Define gRPC contract
3. Add event bus
4. Deploy to Kubernetes
5. Migrate traffic gradually

Instructions

Step 1: Assess Requirements

Use the decision matrix to identify appropriate variant.

Step 2: Choose Architecture

Select Monolith, Service Layer, or Microservice based on needs.

Step 3: Implement Structure

Set up project layout following the chosen blueprint.

Step 4: Plan Migration Path

Document upgrade path for future scaling.

Output

  • Architecture variant selected
  • Project structure implemented
  • Migration path documented
  • Appropriate patterns applied

Error Handling

IssueCauseSolution
Over-engineeringWrong variant choiceStart simpler
Performance issuesWrong layerAdd caching/async
Team frictionComplex architectureSimplify or train
Deployment complexityMicroservice overheadConsider service layer

Examples

Quick Variant Check

# Count team size and DAU to select variant
echo "Team: $(git log --format='%ae' | sort -u | wc -l) developers"
echo "DAU: Check analytics dashboard"

Resources

Next Steps

For common anti-patterns, see clay-known-pitfalls.

More by jeremylongshore

View all
rabbitmq-queue-setup
1,004

Rabbitmq Queue Setup - Auto-activating skill for Backend Development. Triggers on: rabbitmq queue setup, rabbitmq queue setup Part of the Backend Development skill category.

model-evaluation-suite
1,004

evaluating-machine-learning-models: This skill allows Claude to evaluate machine learning models using a comprehensive suite of metrics. It should be used when the user requests model performance analysis, validation, or testing. Claude can use this skill to assess model accuracy, precision, recall, F1-score, and other relevant metrics. Trigger this skill when the user mentions "evaluate model", "model performance", "testing metrics", "validation results", or requests a comprehensive "model evaluation".

neural-network-builder
1,004

building-neural-networks: This skill allows Claude to construct and configure neural network architectures using the neural-network-builder plugin. It should be used when the user requests the creation of a new neural network, modification of an existing one, or assistance with defining the layers, parameters, and training process. The skill is triggered by requests involving terms like "build a neural network," "define network architecture," "configure layers," or specific mentions of neural network types (e.g., "CNN," "RNN," "transformer").

oauth-callback-handler
1,004

Oauth Callback Handler - Auto-activating skill for API Integration. Triggers on: oauth callback handler, oauth callback handler Part of the API Integration skill category.