Discussion :

[acidric]

Bonjour à tous

Je viens ici pour demander un petit peu de conseil et surtout d'orientation...

Voilà, je ne suis pas Dev, mais plutôt IT (je gère de l'IT au quotidien ce qu'on appelle les OPS

Avec la généralisation du devops, les profils comme le mien sont amenés à évoluer et de rajoute donc des
cordes à leur arc...
Je me suis donc mis au HTML/CSS et javascript et j'attaque la partie node JS et vue/js

J’enchaine les tutos, mais maintenant, j’aimerais réaliser un vrai cas pratique au boulot avec un vrai but et personne pour me donner la main, et forcément, ca
Coince, ca marche beaucoup moins bien....

J'ai actuellement des scripts powershell qui tournent pour réaliser certains inventaires de mon infrastructure (3000 machines)
(sorti en JSON) et j'aimerais présenter ca de manière la plus dynamique possible au travers un grid view évolué (de ce genre: https://www.ag-grid.com/example.php#/)

Je précise que ces données font au minimum 10 000 lignes 20 colonnes si je devais mettre ca dans une feuille excel…

Et c’est en termes de conception que je n’arrive pas à prendre de décision…

-Suis-je obligé d’avoir une base de donnée ? Ou un fichier json peux-t il suffire ?
-Le passage pas du frontend (type vue.js) est il obligatoire ? ou du nodes js + javascript + bootstrap peux suffire ?

Je me doute bien que mes questions vont paraitre absurdes pour beaucoup , mais honnêtement le plus dur c’est de comprendre tous les écosystème et leur imbrication plus que la programmation finalement (Et tant qu’à faire, j’essaie d’apprendre des choses qui ne sont pas trop obsolètes et à ma portée)

Merci d’avance à ceux qui pourront m’éclairer

[psychadelic]

ce qu'on appelle les OPS

OPS : Orchestre philharmonique de Strasbourg ? Dur , j'maginais que c'était une bonne place pour faire carrière...

sinon, avant de commencer de faire des choix logiciels il faut maîtriser la structure des données et leur évolution; ne pas mettre la charrue avant les bœufs

sinon 10 000 lignes sur 20 colonnes c'est peanuts

[ABCIWEB]

Je précise que ces données font au minimum 10 000 lignes 20 colonnes si je devais mettre ca dans une feuille excel…

Et c’est en termes de conception que je n’arrive pas à prendre de décision…

-Suis-je obligé d’avoir une base de donnée ? Ou un fichier json peux-t il suffire ?
-Le passage pas du frontend (type vue.js) est il obligatoire ? ou du nodes js + javascript + bootstrap peux suffire ?

Merci d’avance à ceux qui pourront m’éclairer

Un fichier json n'est pas conçu pour faire des recherches ou du tri, contrairement à une bbd qui est optimisée pour cela. Donc si tu veux faire des présentations qui peuvent varier suivant certains critères de recherche il vaut mieux utiliser une base de données.

Il s'agit dans ton exemple de faire des requêtes serveur pour modifier ou afficher du html avec un système de pagination et éventuellement des critères de recherche. On pourrait faire ça aussi simplement avec ajax/php, mais si tu fais des exercices avec vue.js et node.js pourquoi ne pas continuer dans cette direction, cela dit effectivement tu pourrais aussi te limiter à node.js + javascript. Pour dire que rien n'est obligatoire mais l'utilisation d'une bdd est fortement recommandée.

[psychadelic]

Un fichier json n'est pas conçu pour faire des recherches ou du tri, contrairement à une bbd qui est optimisée pour cela. Donc si tu veux faire des présentations qui peuvent varier suivant certains critères de recherche il vaut mieux utiliser une base de données.

c'est pas vrai, si c'est juste pour faire une mise en page dynamique avec filtres de présentation; mettre les données dans un IndexedDB du navigateur est largement suffisant.

[ABCIWEB]

c'est pas vrai, si c'est juste pour faire une mise en page dynamique avec filtres de présentation; mettre les données dans un IndexedDB du navigateur est largement suffisant.

Cela revient à créé une "bdd" côté client à partir du fichier json. Tu as déjà essayé IndexedDB, aussi fiable et simple à mettre en oeuvre qu'une solution serveur ? Et normalement, si problème côté navigateur un code fiable devrait avoir une solution serveur de secours... A priori j'aurais plutôt tendance à l'utiliser pour de gros projets notamment quand on a besoin de la persistance des données, car avec les problèmes potentiels (dépend des navigateurs et de leur capacité), j'ai l'impression que cela représente un gros travail de développement/tests. Si tu as un retour d'expérience, ce serait intéressant (quand tu dis "suffisant", je comprends "possible", mais cela ne renseigne pas sur le reste).

[psychadelic]

facile: => https://gist.github.com/BigstickCarp...9a5d0e3a24814b

[acidric]

merci a tous les deux d'avoir répondu...

désolé pour la réponse tardive, mais la notif du forum n'a visiblement pas fonctionné

En continuant mes recherches, je suis tombé sur un article sympa: https://blog.lesieur.name/pourquoi-v...au-javascript/

Je trouve que ca reflète très bien ma problématique, je veux aller quelque part, il y a une centaine de chemin, je veux juste prendre le moins épineux pour le moment et quand je serais plus doué, je prendrais le chemin de rando

@psychadelic
Quand tu parles de structure de donnée ? tu parles des mes data source ? c'est assez basique, ça sera un 'gros' tableau et oui je sais que 10 000 lignes c'est rien, mais la ou je maîtrise moins justement, c'est si ces 10 000 lignes sont une charge importante ou non pour être traité uniquement par le client, ou faut il absolument le traiter coté serveur (et donc, base de donnée... ?)

Oui j'ai découvert aussi qu'il y avait des moteurs de Template coté Node, why not, je sais que j'ai encore beaucoup à apprendre, je veux juste éviter le superflu pour le moment, même si ca fait bricolage, c'est un début...
C'est assez difficile de s'y retrouver quand même... la dernière fois que j'ai fait du web (ca remonte...) Html/Css php/mysql suffisait, la quand je vois le nombre de module, librairie, gestionnaire de package etc.... c'est impressionnant...

Je jette un oiel à IndexeDB et je vois si j'arrive à y comprendre quelquechose

merci pour votre retour en tout cas

[psychadelic]

@psychadelic
Quand tu parles de structure de donnée ? tu parles des mes data source ? c'est assez basique, ça sera un 'gros' tableau et oui je sais que 10 000 lignes c'est rien, mais la ou je maîtrise moins justement, c'est si ces 10 000 lignes sont une charge importante ou non pour être traité uniquement par le client, ou faut il absolument le traiter coté serveur (et donc, base de donnée... ?)

tout dépends à quoi servent ces données et ce qu'il faut en faire.
Si c'est juste pour un changement dans leur affichage, inutile de leur faire faire des aller-retour entre le serveur et le poste client

Ce que je veux dire, c'est quelque soit la technique à utiliser , il faut un minimum de "plan" quelles sont les interfaces, comment s’enchaînent-ils, quels sont les actions,
est-ce que cela doit pouvoir fonctionner hors ligne ?
bref faire son UML

Et quel est l'environnement ?
Est-ce que tu es dans un réseau privé à haut débit ?

etc..
on peut faire toutes sortes de plans sur la comète

[ABCIWEB]

En continuant mes recherches, je suis tombé sur un article sympa: https://blog.lesieur.name/pourquoi-v...au-javascript/

Je trouve que ca reflète très bien ma problématique, je veux aller quelque part, il y a une centaine de chemin, je veux juste prendre le moins épineux pour le moment et quand je serais plus doué, je prendrais le chemin de rando

Enfin bon tu t'en sort pas mal avec vue + nodejs, je veux dire ce sont de bonnes références en termes de nouvelles technologies web. D'ailleurs j'ai vu un petit tuto assez sympa avec vue et nodeatlas ici.

Si ton but est d'avoir une formation la plus "complète", je veux dire en commençant par les bases, je te conseillerai plutôt d'utiliser une bdd côté serveur avec nodeJs car cela sera beaucoup utile en termes de formation que de savoir manipuler IndexeDB qui ne devrait arriver qu'en complément.

Par exemple si un des intérêts d'IndexeDB est de pouvoir travailler hors ligne, cela présume que tes données peuvent être utilisées sans mise à jour fréquentes. Dans tons cas si c'est pour un inventaire qui donne l'état des lieux une fois par an, c'est concevable, mais pas pour une gestion des stocks qui bouge en permanence, les requêtes serveur sont indispensables.

Par ailleurs construire les pages avec des requêtes serveur c'est aussi s'assurer qu'elles seront bien construites quelque que soit les capacités du périphérique du client, c'est un gage de qualité et d'accessibilité. Aussi je ne suis pas d'accord avec ceux qui cherchent avant tout à éviter des requêtes serveur, la mode du tout client, car cet argument est aujourd'hui souvent surévalué au point d'en sous-estimer les conséquences, mêmes en termes de performances.

Admettons que tu veuille que ta page s'affiche par défaut avec une centaine de lignes représentant les principales données. Avec une bdd, le serveur pourra le faire simplement et rapidement, mais si tu compte uniquement sur le client, cela suppose télécharger systématiquement ton fichier json qui possiblement fera plusieurs Mo ou dizaines de Mo pour des bases un peu grosses, faire le traitement javascript qui s'impose avec IndexeDB, et si le navigateur a suivi la cadence, faire ensuite afficher la page. En termes de réactivité ça laisse à désirer et dépend uniquement des capacités du client, mais ce sera toujours plus long pour le premier affichage quelque soit le client. Si l'utilisateur fait d'autres recherches, peut-être ça ira plus vite qu'une requête serveur mais c'est loin d'être certain et dépendra encore du périphérique qu'il utilise et du volume de tes données.

A mon avis, tu en apprendras bien plus avec une bdd, c'est plus générique, alors qu'IndexeDB ne peut être utilisé que dans des cas spécifiques avec des limitations. Dans ton exemple, je considère la solution "tout client" plutôt comme du bricolage forcé et peu évolutif, surtout qu'avec node.js tu as de quoi répondre en terme de requêtes et de mise à jour des données client puisqu'il est justement optimisé pour ça. Ou éventuellement tu pourrais créer une bdd côté serveur directement à partir de ton fichier texte. En php il existe des routines assez simples pour créer du SQlite à partir d'un fichier texte, il y a probablement l'équivalent avec node.js (les termes "node.js sqlite" donnent de nombreux résultats dans un moteur de recherche).

[Marco46]

J'ai développé le même genre d'outil frontend pour les devops lors de ma dernière mission. Sauf que j'ai pas dev le backend qui me retourne toutes les données (même ordre de grandeur que les tiens) au démarrage de la webapp.

Avec des volumes de quelques milliers d'enregistrements une base de données c'est de l'overkill. Ton volume de données doit représenter quelques dizaines voire une centaine de ko. C'est vraiment rien du tout.

J'ai utilisé Fuse.js pour gérer les recherches sur les configurations des différents environnements / projets. C'est très très rapide. La recherche peut être implémentée côté front avec ce genre de volume, ça ne pose pas de soucis. Il faut comprendre que le JavaScript avec des moteurs comme V8 de nos jours ça a des performances très très proches des langages compilés (d'ailleurs V8 "compile" à la volée). Il faut avoir des ordres de grandeurs de l'ordre de centaines de milliers voire millions d'enregistrement pour nécessiter un traitement côté back et là il faudra probablement choisir un langage différent de JavaScript. Node supporte assez mal les calculs dans son fonctionnement (question d'architecture, on est sur un seul thread).