Skip to main content

api-developer

Use when building the local API/server layer that serves the UI. Handles project CRUD, seed job orchestration, and proxies to Webiny CMS GraphQL. Uses DI patterns from project-architecture. Invoke BEFORE writing any server/API code.

معلومات المصدر

المستودع
webiny/data-mock
آخر نشاط في المصدر
٤ سبتمبر ٢٠٢٦ في ١٠:١٢
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
١
التفرعات
٠

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
api-developer
description
Use when building the local API/server layer that serves the UI. Handles project CRUD, seed job orchestration, and proxies to Webiny CMS GraphQL. Uses DI patterns from project-architecture. Invoke BEFORE writing any server/API code.
# API Developer Guide API lives in `src/api/`. Serves the local UI — manages Webiny project configs (SQLite), orchestrates data seeding jobs, and proxies GraphQL calls to Webiny CMS instances. All logic in use cases, all persistence in repositories. ## Architecture ``` Route (thin) → UseCase (logic) → Repository (persistence) → SQLite / Webiny GraphQL ↑ GraphQLService (Webiny CMS client) ``` - **Route handler**: thin dispatcher. Receives request, resolves use case from container, calls execute, sends result. - **UseCase**: single `execute()` method. Orchestrates repositories and services. Returns `Result<T, E>`. Transient scope. - **Repository**: data access (SQLite for project configs, seed history). Singleton scope. Returns `Result<T, E>`. - **GraphQLService**: wraps Webiny CMS GraphQL API calls. Singleton scope. Handles auth tokens per-project. - **GeneratorService**: orchestrates field value generation using the generator registry. ## Directory Structure ``` src/api/ ├── server.ts # HTTP server setup ├── routes.ts # Route registration ├── feature.ts # Root ApiFeature ├── features/ │ └── {domain}/ # e.g. projects, seeding, models │ ├── {operation}/ # e.g. list, create, seed │ │ ├── abstractions/ │ │ │ ├── {Name}UseCase.ts │ │ │ └── {Name}Repository.ts │ │ └── {Name}UseCase.ts │ ├── abstractions/ │ │ └── index.ts │ ├── errors.ts │ ├── routes.ts │ └── feature.ts src/shared/ ├── db/ │ └── schema.ts # SQLite table schemas ├── errors.ts └── types.ts ``` ## Key Domains ### Projects - CRUD for Webiny project configurations (name, API URL, auth token, tenant ID) - Stored in SQLite via `ProjectRepository` - Replaces the current `.env`-based configuration ### Seeding - Orchestrates creating mock entries in a Webiny CMS instance - User selects: project → models → entry count per model - Uses `GeneratorRegistry` to create field-appropriate fake data - Tracks seed history (what was seeded, when, how many) ### Models - Fetches available CMS models from a Webiny project via GraphQL - Caches model definitions locally for offline field introspection ## GraphQL Service Wraps the existing GraphQL application logic. Per-project auth. ```ts // abstractions/GraphQLService.ts export interface IGraphQLService { listModels(project: Project): Promise<Result<Model[], GraphQLService.Error>>; createEntry(project: Project, modelId: string, data: Record<string, unknown>): Promise<Result<Entry, GraphQLService.Error>>; listEntries(project: Project, modelId: string): Promise<Result<Entry[], GraphQLService.Error>>; } ``` ## SQLite Database Project configs and seed history stored in SQLite (replaces .env). ```ts // Tables: projects, seed_runs, seed_run_entries const project = { id: "uuid", name: "My Webiny Project", apiUrl: "https://xxx.cloudfront.net/cms/manage/en-US", token: "pat_xxx", tenantId: "root", createdAt: "2024-01-01T00:00:00Z", }; ``` ## Commands - `yarn dev` — start API + UI with file watching - `yarn lint` — oxlint (src/) - `yarn format:check` — oxfmt (src/) - `yarn compile` — TypeScript strict mode ## Key Rules - ALL input validated via Zod - Routes are thin — resolve use case, call execute, send result - Use cases return `Result<T, E>` — never throw for expected failures - API errors extend `BaseError` - One use case per operation, one repository per operation — single `execute()` method each - No multi-method repositories — split into ListXxxRepository, CreateXxxRepository, etc. - Use cases are transient, repositories and services are singleton - Child container per request — no singleton spill between requests
عرض على GitHub