Générer un gros fichier d'export

Bonjour,

Je rencontre une difficulté sur un de mes projets.
En effet, je dois pouvoir proposer à l'administrateur un export complet d'une table de 130.000 lignes depuis SQL Server.
Ce fichier CSV doit être généré et récupéré depuis le front ReactJS via un bouton sur l'application.
La partie serveur est une API REST développée en NodeJS.

Toutefois je me vois mal envoyer autant de données depuis l'API sans faire crasher le poste client.
Avez-vous une idée à me proposer ?

Petite précision je n'ai pas accès aux serveurs, juste aux répertoires de mes applications (Node + React)

Merci d'avance.

Et voilà, tu fais face à l’absurdité des frameworks de front-end qui sont si populaires aujourd’hui. On délègue à la partie cliente la charge de travail qui revient normalement au serveur.

Je n’ai pas de solution, mais il m’a paru pertinent de répondre pour te dire que je n’ai pas de solution. Autrement tu risquais de n’avoir jamais de réponse.

Le problème principal est la limite d’allocation de mémoire de JS qui est très variable d’un navigateur à l’autre et d’un système à l’autre. Ça peut monter jusqu’à plusieurs Go comme être limité à une centaine de Mo. Ton script n’a aucun contrôle là-dessus, et je ne connais pas de moyen fiable de détecter la limite.

La seule idée qui me vient, là comme ça, c’est juste une bidouille : proposer à l’utilisateur de télécharger le fichier en plusieurs fragments, et le laisser recoller les morceaux à la main. J’imagine que ça ne te conviendra pas :roll:

Combien de temps met cette archive à être générée ?

Pour moi c'est au serveur de la créer donc :

- Requête sur l'API pour demander un export
- Génération de l'export par le serveur
- Réponse avec une url de téléchargement.
- Tu déclenche le téléchargement via le navigateur.

Il faut gérer coté serveur le fait de supprimer le fichier après un temps donné.

Si la génération de l'archive est longue , il faut envisager une websocket pour indiquer la progression , au à minima un polling sur une uri qui présente l'avancement.

Tu utilises SQL Server Reporting Services pour générer ton CSV.
Ou tu délègues cette partie à un serveur d'application Java ou IIS car eux sont multithread et ne seront pas bloqués par le fetch des enregistrements et l'enregistrement du csv sur disque. En présentant cela comme un "serveur de rapports"
Ou tu lances un batch via child_process (à tester)


Un problème similaire est arrivé à un de mes développeurs senior générant ses rapports via une usine à gaz géante (fichiers batchs -> sql serveur -> xml -> requêtes xpath -> export pdf): la génération du rapport prenait trop de temps la requête partait en timeout au bout de 3 minutes (sans parler des problèmes de conflit d'identités entre IIS et les scripts).

Plutôt que de réinventer la roue, j'ai installé une queue des messages (MSMQ, attention a la supervision) et demandé au développeur d'envoyer un message avec le nom du script et les paramètres.
J'ai ensuite codé un service simple scannant les messages y transitant, déclenchant l'appel à ses fichiers batchs, et renvoyant un message de fin de traitement : comme ce service n'est pas lié à IIS, il n'est pas limité dans le temps de traitement.

C'est le découplage.

Je supprime mon message puisque j'ai mal lu et que Grunk a déjà répondu tout bon !