Portfolio BUT2
Technique

Trace 4 - Chunks, batches et NDJSON

Découpage des données d'export par feuille et batch pour éviter les gros payloads.

Conception d'une architecture d'export robuste

Exploitation et traitement de données volumineuses

Trace 4

Envoyer les données par feuille et par batch

Trace 4 - Flux final : chaque batch est écrit temporairement puis lu ligne par ligne par OpenSpout.

La Trace 4 ci-contre décrit le mécanisme de chunks et de batches utilisé pour les gros exports Cockpit. Elle montre une étape plus concrète que la Trace 3 : une fois le job créé, il faut envoyer un grand volume de données sans produire un payload trop lourd pour le navigateur ou pour l'API PHP. Cette partie du travail m'a demandé de découper un traitement lourd en un protocole simple.

Les zones de la trace représentent le découpage par feuille, puis par batch. Au lieu d'envoyer un seul JSON contenant toutes les lignes, le frontend envoie plusieurs morceaux. Le backend les stocke ensuite dans des fichiers temporaires au format NDJSON, ce qui permet à OpenSpout de relire les lignes progressivement pendant la génération du fichier. Le point essentiel était de traiter des volumes sans les charger intégralement, sinon le découpage réseau n'aurait pas résolu le problème mémoire.

  1. La route jobs/:id/chunk est réutilisée avec mode: sheet_batch.
  2. Le backend écrit les lignes dans des fichiers sheet_N.ndjson et met à jour un manifest.json.
  3. Au start, OpenSpout lit les lignes batch par batch et évite de charger tout le payload en mémoire.

Exemple de chunk envoyé

{
  "mode": "sheet_batch",
  "sheetName": "Ok Démarrages Opérations",
  "sheetIndex": 5,
  "columns": ["Date", "Poste", "Contrôle", "Résultat"],
  "rows": [["2026-02-23", "FR2", "Opération 1", "OK"]],
  "batchIndex": 2,
  "totalBatches": 12
}

Structure temporaire côté API PHP

fichiers/cockpit/.payloads/export_job_36/
  manifest.json
  sheet_0.ndjson
  sheet_1.ndjson
  sheet_2.ndjson

La première difficulté n'était pas seulement d'envoyer les données en plusieurs requêtes. Si le backend reconstruit ensuite un énorme tableau en mémoire, le problème revient au moment de la génération. C'est pour cette raison que la Trace 4 met aussi en avant la structure temporaire côté API : les fichiers sheet_N.ndjson évitent de charger tout le contenu en une seule fois.

Dans la Trace 4, le vrai changement n'est donc pas seulement "envoyer en morceaux", mais aussi "stocker et relire en streaming". C'est ce choix qui rend la solution plus adaptée aux exports volumineux.

On this page