Choose and implement FireCrawl validated architecture blueprints for different scales. Use when designing new FireCrawl integrations, choosing between monolith/service/microservice architectures, or planning migration paths for FireCrawl applications. Trigger with phrases like "firecrawl architecture", "firecrawl blueprint", "how to structure firecrawl", "firecrawl project layout", "firecrawl microservice".
Generates FireCrawl architecture blueprints and migration paths for monolith, service layer, or microservice implementations.
/plugin marketplace add jeremylongshore/claude-code-plugins-plus-skills/plugin install firecrawl-pack@claude-code-plugins-plusThis skill is limited to using the following tools:
Three validated architecture blueprints for FireCrawl integrations.
Best for: MVPs, small teams, < 10K daily active users
my-app/
├── src/
│ ├── firecrawl/
│ │ ├── client.ts # Singleton client
│ │ ├── types.ts # Types
│ │ └── middleware.ts # Express middleware
│ ├── routes/
│ │ └── api/
│ │ └── firecrawl.ts # API routes
│ └── index.ts
├── tests/
│ └── firecrawl.test.ts
└── package.json
// Direct integration in route handler
app.post('/api/create', async (req, res) => {
try {
const result = await firecrawlClient.create(req.body);
res.json(result);
} catch (error) {
res.status(500).json({ error: error.message });
}
});
Best for: Growing startups, 10K-100K DAU, multiple integrations
my-app/
├── src/
│ ├── services/
│ │ ├── firecrawl/
│ │ │ ├── client.ts # Client wrapper
│ │ │ ├── service.ts # Business logic
│ │ │ ├── repository.ts # Data access
│ │ │ └── types.ts
│ │ └── index.ts # Service exports
│ ├── controllers/
│ │ └── firecrawl.ts
│ ├── routes/
│ ├── middleware/
│ ├── queue/
│ │ └── firecrawl-processor.ts # Async processing
│ └── index.ts
├── config/
│ └── firecrawl/
└── package.json
// Service layer abstraction
class FireCrawlService {
constructor(
private client: FireCrawlClient,
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('firecrawl.post-create', result);
return result;
}
}
Best for: Enterprise, 100K+ DAU, strict SLAs
firecrawl-service/ # Dedicated microservice
├── src/
│ ├── api/
│ │ ├── grpc/
│ │ │ └── firecrawl.proto
│ │ └── rest/
│ │ └── routes.ts
│ ├── domain/
│ │ ├── entities/
│ │ ├── events/
│ │ └── services/
│ ├── infrastructure/
│ │ ├── firecrawl/
│ │ │ ├── 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 firecrawl-service
├── payment-service/
└── notification-service/
// Event-driven with domain isolation
class FireCrawlAggregate {
private events: DomainEvent[] = [];
process(command: FireCrawlCommand): void {
// Domain logic
const result = this.execute(command);
// Emit domain event
this.events.push(new FireCrawlProcessedEvent(result));
}
getUncommittedEvents(): DomainEvent[] {
return [...this.events];
}
}
// Event handler
@EventHandler(FireCrawlProcessedEvent)
class FireCrawlEventHandler {
async handle(event: FireCrawlProcessedEvent): Promise<void> {
// Saga orchestration
await this.sagaOrchestrator.continue(event);
}
}
| Factor | Monolith | Service Layer | Microservice |
|---|---|---|---|
| Team Size | 1-5 | 5-20 | 20+ |
| DAU | < 10K | 10K-100K | 100K+ |
| Deployment Frequency | Weekly | Daily | Continuous |
| Failure Isolation | None | Partial | Full |
| Operational Complexity | Low | Medium | High |
| Time to Market | Fastest | Moderate | Slowest |
Monolith → Service Layer:
1. Extract FireCrawl code to service/
2. Add caching layer
3. Add background processing
Service Layer → Microservice:
1. Create dedicated firecrawl-service repo
2. Define gRPC contract
3. Add event bus
4. Deploy to Kubernetes
5. Migrate traffic gradually
Use the decision matrix to identify appropriate variant.
Select Monolith, Service Layer, or Microservice based on needs.
Set up project layout following the chosen blueprint.
Document upgrade path for future scaling.
| Issue | Cause | Solution |
|---|---|---|
| Over-engineering | Wrong variant choice | Start simpler |
| Performance issues | Wrong layer | Add caching/async |
| Team friction | Complex architecture | Simplify or train |
| Deployment complexity | Microservice overhead | Consider service layer |
# Count team size and DAU to select variant
echo "Team: $(git log --format='%ae' | sort -u | wc -l) developers"
echo "DAU: Check analytics dashboard"
For common anti-patterns, see firecrawl-known-pitfalls.
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.