Architecture full-stack : client React, API Node et CORS

Une application full-stack associe deux programmes :

• le client : une application React (construite avec Vite) qui s’exécute dans le navigateur ;
• le serveur : une API Express qui s’exécute sur Node.js et accède à la base de données.

Ils ne partagent ni mémoire ni variables : ils communiquent uniquement par des requêtes HTTP échangeant du JSON. L’ensemble des routes, formats et codes d’erreur forme le contrat d’API ; le documenter (README, OpenAPI) ou le partager sous forme de schémas évite bien des malentendus.

Organiser le dépôt

mon-app/
  package.json          scripts communs (workspaces npm)
  client/               React + Vite
    src/App.jsx
    vite.config.js
  server/               Express 5
    src/app.js
    src/server.js

{
  "private": true,
  "workspaces": ["client", "server"],
  "scripts": {
    "dev": "npm run dev -w server & npm run dev -w client",
    "build": "npm run build -w client",
    "test": "npm test -w server"
  }
}

En développement, deux serveurs tournent : Vite sur http://localhost:5173 (rechargement à chaud) et l’API sur http://localhost:3000.

Le proxy de Vite

Pour le navigateur, localhost:5173 et localhost:3000 sont deux origines différentes (le port fait partie de l’origine). Le plus simple en développement est de demander à Vite de relayer les appels /api :

// client/vite.config.js
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: { "/api": "http://localhost:3000" },  // /api/notes -> http://localhost:3000/api/notes
  },
});

Le code React appelle alors simplement fetch("/api/notes") : même origine, aucun problème de CORS. En production, on reproduit la même chose en servant le client et l’API depuis le même domaine (leçon 5).

Quand faut-il CORS ?

La politique de même origine empêche un script d’une origine de lire les réponses d’une autre. Si votre client est sur app.exemple.fr et l’API sur api.exemple.fr, l’API doit l’autoriser explicitement avec des en-têtes CORS :

const ORIGINES = new Set(["https://app.exemple.fr", "http://localhost:5173"]);

app.use((req, res, next) => {
  const origin = req.get("origin");
  if (origin && ORIGINES.has(origin)) {
    res.set("Access-Control-Allow-Origin", origin);       // renvoyer l'origine autorisée
    res.set("Access-Control-Allow-Credentials", "true");  // si l'on utilise des cookies
    res.set("Vary", "Origin");                            // le cache dépend de l'origine
  }
  if (req.method === "OPTIONS") {                         // requête préliminaire (preflight)
    res.set("Access-Control-Allow-Methods", "GET,POST,PATCH,DELETE");
    res.set("Access-Control-Allow-Headers", "Content-Type");
    return res.status(204).end();
  }
  next();
});

Le paquet cors fait la même chose : app.use(cors({ origin: [...], credentials: true })). Deux règles : liste blanche d’origines, et jamais Access-Control-Allow-Origin: * avec des cookies (les navigateurs le refusent d’ailleurs). CORS protège les utilisateurs dans leur navigateur ; ce n’est pas un mécanisme d’authentification de l’API.

Variables d’environnement côté client

Vite n’expose au code React que les variables préfixées VITE_ (import.meta.env.VITE_API_URL). Elles sont intégrées au JavaScript livré : tout le monde peut les lire. Les secrets (clé d’API privée, mot de passe de base) restent exclusivement côté serveur.

À retenir

Deux programmes, un contrat HTTP/JSON. En développement, le proxy Vite évite CORS ; si les origines diffèrent en production, configurez CORS avec une liste blanche. Aucun secret dans le client.