Skip to main content

​
Principes de conception

KitAsso repose sur 3 piliers architecturaux :

​
1. Feature-Based Structure

Organisation par domaine métier plutôt que par type technique. 
src/features/
├── tools/
│   ├── api/
│   ├── components/
│   ├── hooks/
│   └── types/
├── workflows/
└── tool-packs/
Avantages :
  • Isolation des fonctionnalités
  • Facilite le travail en équipe
  • Suppression/ajout de features sans impact

En savoir plus

Guide détaillé de l’approche feature-based

​
2. API Layer découplée

Séparation stricte entre :
  • Route Handlers (app/api/) : points d’entrée HTTP
  • Business Logic (src/features/*/api/) : règles métier
  • Data Access (Supabase client) : accès base de données
// app/api/tools/route.ts
import { getTools } from '@/features/tools/api/tools-api';

export async function GET() {
  const tools = await getTools();
  return Response.json(tools);
}
La logique métier reste testable indépendamment des routes Next.js

​
3. Patterns standardisés

Modals

Pattern d’ouverture via URL

Forms

React Hook Form + Zod

Routes

App Router + Parallel Routes

Voir tous les patterns

Documentation complète des patterns

​
Schéma visuel

​
Structure de dossiers

kitasso/
├── app/                  # Next.js App Router
│   ├── (auth)/          # Routes authentifiées
│   ├── (public)/        # Routes publiques
│   └── api/             # API endpoints
│
├── src/
│   ├── features/        # Features métier
│   │   ├── tools/
│   │   ├── workflows/
│   │   └── tool-packs/
│   │
│   ├── shared/          # Code partagé
│   │   ├── components/
│   │   ├── hooks/
│   │   └── utils/
│   │
│   └── lib/             # Clients externes
│       └── supabase/
│
└── supabase/            # Migrations & config
Contient toutes les routes de l’application :
  • (auth)/ : pages nécessitant une authentification
  • (public)/ : pages accessibles sans compte
  • api/ : endpoints API REST
Chaque feature contient :
  • api/ : logique métier et accès données
  • components/ : composants UI spécifiques
  • hooks/ : hooks React custom
  • types/ : types TypeScript
Éléments réutilisables entre features :
  • Composants UI génériques
  • Hooks utilitaires
  • Fonctions helpers
Configuration des services tiers :
  • Client Supabase
  • Authentification
  • Storage
1

Comprendre l'approche feature-based

Architecture feature-basedDécouvrez pourquoi nous organisons le code par domaine métier
2

Explorer les patterns

Patterns de codeModals, forms, routes : les standards à suivre
3

Découvrir l'API

API OverviewDocumentation des endpoints disponibles

​
Principes directeurs

Modularité

Chaque feature peut être activée/désactivée indépendamment

Testabilité

La logique métier est découplée du framework

Type Safety

TypeScript strict + validation Zod partout

Performance

Server Components par défaut, hydratation minimale
Ne contournez pas l’architecture feature-based en créant des dossiers par type technique (components/, hooks/, utils/ à la racine)