Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre averti Avatar de sourivore
    Homme Profil pro
    Lead Tech Front-End
    Inscrit en
    juin 2005
    Messages
    450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Lead Tech Front-End

    Informations forums :
    Inscription : juin 2005
    Messages : 450
    Points : 334
    Points
    334

    Par défaut 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.
    Toi aussi, crée ton armée de soldat de plomb :
    http://souris-bleues.minitroopers.fr/

  2. #2
    Expert confirmé Avatar de Watilin
    Homme Profil pro
    En recherche d'emploi
    Inscrit en
    juin 2010
    Messages
    2 536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : En recherche d'emploi

    Informations forums :
    Inscription : juin 2010
    Messages : 2 536
    Points : 5 287
    Points
    5 287

    Par défaut

    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
    La FAQ JavaScript – Les cours JavaScript
    Un article du MDN n’a pas de version française ? Je peux peut-être le traduire, envoyez-moi un MP

    La touche F12 : l’outil indispensable à tout développeur JavaScript !

  3. #3
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    5 207
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 5 207
    Points : 13 761
    Points
    13 761

    Par défaut

    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  4. #4
    Membre chevronné Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : octobre 2007
    Messages : 890
    Points : 1 992
    Points
    1 992

    Par défaut

    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.

  5. #5
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    3 521
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 3 521
    Points : 13 843
    Points
    13 843

    Par défaut

    Je supprime mon message puisque j'ai mal lu et que Grunk a déjà répondu tout bon !
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

Discussions similaires

  1. Réponses: 7
    Dernier message: 16/05/2007, 10h47
  2. Optimisation de la lecture de tres gros fichiers
    Par Lydie dans le forum C++Builder
    Réponses: 4
    Dernier message: 12/07/2004, 14h09
  3. [JDOM] Gestion "gros fichiers"
    Par Haazheel dans le forum XML
    Réponses: 10
    Dernier message: 17/10/2003, 13h42
  4. Un langage pour lire, traiter et écrire de gros fichiers
    Par March' dans le forum Langages de programmation
    Réponses: 19
    Dernier message: 07/04/2003, 15h26
  5. XML DOM et gros fichiers
    Par Manu_Just dans le forum APIs
    Réponses: 4
    Dernier message: 28/03/2003, 09h50

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo