paint-brush
Voici pourquoi vous ne devriez pas utiliser Graphviz pour les DAG : ce que vous devriez utiliser à la placepar@s0l0ist
1,198 lectures
1,198 lectures

Voici pourquoi vous ne devriez pas utiliser Graphviz pour les DAG : ce que vous devriez utiliser à la place

par Nick Angelou5m2024/01/24
Read on Terminal Reader

Trop long; Pour lire

tl;dr : utilisez Vizdom.dev pour restituer les DAG écrits en langage DOT et bénéficiez d'accélérations allant jusqu'à 30 x
featured image - Voici pourquoi vous ne devriez pas utiliser Graphviz pour les DAG : ce que vous devriez utiliser à la place
Nick Angelou HackerNoon profile picture
0-item
1-item


Spoiler : utilisez Vizdom.dev pour restituer les DAG écrits en langage DOT


En tant que développeur de logiciels, j'ai parfois travaillé avec des DAG, la plupart impliquant leur visualisation. Dans de nombreux cas, j’ai eu du mal à obtenir un rendu rapide et je me suis retrouvé à chercher des outils.


Heureusement, il y a le fidèle Visualisation graphique outil capable de restituer des graphiques écrits en langage DOT – Parfait !


Sauf…

  • Cela ne fonctionne pas bien sur le Web*
  • je dois l'installer
  • Il ne gère pas les fichiers DOT/GV en ligne

Considérations

*D'accord, techniquement , Graphviz peut être compilé dans WebAssembly, et quelques personnes talentueuses ont réussi à construire quelques projets intéressants tels que celui de dreampuf. éditeur , celui de Nike edotor.net , et celui de Magjac éditeur - chacun avec sa propre touche. J'ai encore du mal à intégrer ces rendus sans les exporter vers un SVG (ou autre support).


Par exemple, je souhaite stocker mon graphique dans Notion.so en collant simplement un lien qui restitue automatiquement le graphique.


je pourrais utiliser SirèneJS qui rend les graphiques assez proprement et fonctionne étonnamment bien — c'est l'une des nombreuses raisons pour lesquelles il a Plus de 64 000 démarrages sur GitHub . Je peux également intégrer des graphiques dans Notion/GitHub en utilisant markdown, mon chou !


Malheureusement, je dois traduire DOT dans la saveur de démarque requise par Mermaid. Pour les représentations textuelles plus petites, je peux utiliser ChatGPT pour les convertir à ma place, mais il commet fréquemment des erreurs grammaticales et le graphique refusera de s'afficher, ce qui le rend peu fiable en tant que source d'automatisation.


Ensuite il y a Terrastruct.com ce qui est incroyable pour gérer des diagrammes construits à la main , mais comme mes malheurs de Mermaid, je ne peux pas convertir DOT en D2 de manière fiable. Je suppose que si vous souhaitez créer des diagrammes à la main, il s'agit d'un coût unique acceptable. En général, c'est un outil fantastique. Gloire!

Le problème

  • Je souhaite restituer les sorties DOT générées par programme – aucun des outils ne semble m'aider à atteindre cet objectif.


  • Je souhaite intégrer des liens qui restituent des graphiques.


  • Je souhaite stocker le rendu en ligne pour des mises à jour ou le comparer visuellement avec d'autres graphiques.

La solution

Ouais, j'ai construit un application pour ça 🎉


…Et il est entièrement construit en Rust 🦀 avec un grand merci à Leptos


tl;dr — une application simple et spécialement conçue pour restituer rapidement les DAG en ligne


Minimiser les croisements de bords dans la génération de graphiques, un défi NP-difficile reconnu est essentiel pour créer des graphiques visuellement attrayants. L'équipe de Terrastruct a publié un remarquable article de blog approfondir ce sujet. Inspiré de manière significative par les algorithmes de mise en page DagreJS et par l'article perspicace « A Technique for Drawing Directed Graphs ¹ », j'ai développé une variante dans Rust.


Cette version est particulièrement efficace pour le rendu de graphiques hiérarchiques, exploitant la complexité complexe de ce problème.


Le rendu de grands DAG (plus de 500 nœuds/bords) a tendance à être quelque peu lent avec Graphviz. Dagré + D3 ( d3-graphviz et dérivés) finissent par être un peu plus rapides et offrent d'excellentes animations/personnalisations de style. Pourtant, j'ai eu l'impression qu'ils manquent des fonctionnalités fournies par le langage DOT, à savoir que les attributs de style ne sont souvent honorés que si vous effectuez un rendu avec Graphviz.


Vizdom produira des résultats très similaires à Dagre mais davantage alignés sur la spécification DOT et les comportements de style de Graphviz. Cependant, il n'a pas de parité de fonctionnalités avec Graphviz, et les instructions/attributs qui ne sont pas pris en charge sont simplement ignorés.


Je pense que c'est un bon compromis pour les types d'attributs générés par programme que le DOT consommera.


Fonctionnalités de Vizdom

  • 🚀 Rendu ultra-rapide
  • 💾 Stockez les graphiques dans des liens
  • 0️⃣ Zéro dépendance et aucune installation requise

Vitesse de rendu

Eh bien, c'est une comparaison entre des pommes et des oranges. Graphviz produit toujours d'excellentes visualisations et prend en charge davantage moteurs de mise en page , donc je compare subjectivement Vizdom contre le moteur DOT de Graphviz, en le limitant aux seuls DAG, et encore plus en le réduisant à une liste de fonctionnalités étroites du langage DOT.


Oui, je sais que c'est terrible de comparer des années d'expérience et d'outils autour de la séquence de plus de 30 ans qu'est Graphviz, mais pour mon cas d'utilisation restreint, c'est très rapide. Voici quelques temps de mur sur mon Macbook Pro M1 pour le rendu un graphique assez grand avec ~400 nœuds :


  • Graphviz natif : ~30 secondes
  • Chrome (WASM) Graphviz : plante*
  • Chrome (Javascript) DagreJS : ~10 secondes
  • Chrome (WASM) Vizdom : ~1 seconde**


* Il plante car l'indicateur emscripten, ALLOW_MEMORY_GROWTH=1 , n'est pas défini, limitant ainsi la mémoire totale à 16 Mo. Cela peut être corrigé, mais je n'ai pas trouvé de projet en ligne capable de gérer le graphique en question.


** L'exemple de graphique est rendu en sélectionnant Example 14 dans la vue de l'éditeur. L'actualisation de la page entraînera l'actualisation de la page et l'obtention d'un 414 car l'URI qui persiste dans le graphique est trop grand. Je travaille sur une meilleure solution pour stocker des graphiques plus grands.


Rendu SVG de l'exemple 14

Stocker les graphiques dans des liens

Vous remarquerez que lorsque vous apportez des modifications au fichier DOT, l'URL met immédiatement à jour quelques paramètres de requête pour stocker les options de graphique et de mise en page, vous permettant de toujours référencer une copie de vos données simplement en stockant le lien !


Il y a un hic : les graphiques de grande taille ont tendance à rendre l'URI trop grand pour AWS (où Vizdom est actuellement hébergé) et d'autres équilibreurs de charge.


Je travaille actuellement sur une solution pour gérer des graphiques plus grands, mais en attendant, j'ai inclus quelques façons de conserver et de stocker des graphiques :


  • Copiez un lien intégrable qui affiche automatiquement une vue qui maximise le graphique.


  • Copiez un extrait d'iframe pour l'intégrer dans n'importe quelle application prenant en charge leur rendu.


  • Ou téléchargez simplement le SVG rendu.


Voici un exemple de ce à quoi ressemble la vue de l'éditeur du trace pprof pour dégonfler :

Accédez à la vue Éditeur et chargez Example 42


Vue différentielle

Parfois, je me suis retrouvé à essayer de comparer deux graphiques que j'avais générés, alors pendant que j'y étais, j'ai ajouté un visionneuse de différences pour voir visuellement les changements entre deux graphiques différents.


Légende des couleurs :

  • Rouge : Supprimé
  • Orange : modifié
  • Vert : ajouté


Voici quelques clichés :

Cliquez-moi : changer un ID de nœud de « e » à « f »


Cliquez-moi : ajout de « cluster=true »


Orientation future

Vizdom est toujours un travail en cours, et à mesure qu'il continue d'évoluer, je suis conscient que le parcours de perfectionnement de cet outil est aussi dynamique que le domaine de la visualisation graphique lui-même. Même si je suis fier de ce que Visualisation a réalisé jusqu'à présent, je suis encore plus enthousiasmé par son potentiel. C’est là que vous, lecteur et utilisateur potentiel, intervenez.


Si vous avez des commentaires, n'hésitez pas à m'envoyer un message sur Gitter ou Discorde .


Merci d'avoir lu — Si vous avez apprécié cet article, suivez-le !


[1] : ER Gansner, E. Koutsofios, SC North et K. . -P. Vo, « Une technique pour dessiner des graphiques orientés », dans IEEE Transactions on Software Engineering, vol. 19, non. 3, pp. 214-230, mars 1993, doi : 10.1109/32.221135.


Également publié ici