- Routes en React.lazy (sauf connexion et accueil) avec un Suspense dans
la zone de contenu ; recharts n'est plus préchargé. JS initial :
1,72 Mo -> 625 Ko (183 Ko gzip). Rechargement automatique unique si un
ancien fichier JS a disparu après un déploiement, et ErrorBoundary par
page pour garder le menu affiché en cas d'erreur.
- Authentification unifiée sur le cache React Query ['/api/user'] : un
seul GET /api/user pour toute l'application (au lieu de 4 à 5 par
page), plus de rechargement complet après la connexion.
- Pas de nouvel essai sur les erreurs 4xx ; fournisseurs et magasins en
cache 5 minutes ; valeur du StoreContext mémoïsée et redimensionnement
qui ne re-rend que lorsque le palier d'écran change.
- Pages : requêtes inutilisées ou en double supprimées, appels lancés
seulement une fois l'utilisateur connu, invalidations ciblées au lieu
de rechargements complets, filtres et tris mémoïsés, anciennes données
gardées (et estompées) pendant un changement de filtre ou de mois,
recherche DLC mobile temporisée, vérifications de factures à
concurrence bornée, navigation interne sans rechargement de la page.
- index.html : script de bannière Replit retiré, lang="fr".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MsDJjQrAggcJwbbBtKhgyb
The app degraded progressively over a year of data growth. Four causes,
all cumulative:
1. No indexes. Apart from primary keys, unique constraints and
session.expire, no table carried an index. PostgreSQL does not index
foreign keys automatically, so every filter and join on group_id,
supplier_id, order_id and the date columns did a sequential scan.
Worst offender: user_groups.user_id, read by getUserWithGroups() on
every authenticated request.
2. N+1 in the order and delivery listings. getOrders,
getOrdersByDateRange, getDeliveries and getDeliveriesByDateRange
issued one to two queries per row to load relations. Relations are now
loaded in bulk and grouped in Node: three queries regardless of volume.
3. /api/sync-order-delivery-status reloaded the whole deliveries table on
every iteration of its loop over orders. It now uses the deliveries
getOrders() already attaches.
4. clearExpiredCache() was implemented but never called, so
invoice_verification_cache grew without bound. Now scheduled every 6h.
Also replaces the full-history downloads on the Groups and Suppliers
pages, which fetched every order and delivery with nested relations only
to count rows, with aggregate endpoints that count in the database.
Indexes are created via scripts/auto-migrate-production.sh, the script
that actually runs at deploy time, using CREATE INDEX CONCURRENTLY so no
write lock is taken. Note that server/migrations.ts explicitly ignores
the migrations/ directory and runs only hardcoded migrations; the SQL
file added there is for reference and manual application.
Verified: typecheck baseline 440 errors, 430 after, none new in the
changed code; vite build passes; server boots; functional test confirms
the aggregate endpoints match the source data including the delivered
count.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- New contacts table (group_id, name, role, phone, email, notes) per store
- Suppliers table: add email field with form and card display
- Page /contacts: two-column layout (suppliers read-only / free contacts CRUD)
- Permissions: read all roles, create/edit/delete admin + directeur + manager
- Admin can filter contacts by store; other roles see their own stores only
- Migration SQL: 20260515_add_contacts_and_supplier_email.sql
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude
MichaelandClaude Fable 5
michaelschal
LogiFlow