How I built Advanced SDN PoC Designer with mxGraph & VueJS

Published in

Geek Culture

5 min readNov 20, 2021

**SDN PoC Designer (Attribution GreekMythology.com)**

My third follow-up article in the perilous world of network visualizations, yet another streak of relentless research with its own taste of thrills. If you never heard of mxGraph — then it’s aged, buried under millennial jargon’s.

Spawned from JGraph (Java), mxGraph is based on JavaScript, most of its codebase is inspired by JGraph. From a lineage point it roughly started in late 2005, and was EOL after 2020, as the Github note reads:

NOTE 09.11.2020 : Development on mxGraph has now stopped, this repo is effectively end of life.

You can still find it rooted in JGraph aka. Diagrams.net, which works on both desktop and web. One of the interesting part of this library is its XML-based file format which works flawlessly on diagram files created in 2005.

What is mxGraph? 🤨

In a nutshell, it’s a JavaScript developer library aimed to provide plug-and-play components to draw, move and interact with contextual diagram or graph elements with properties. It’s written in pure JavaScript, no transpilers or NPM dependencies. A plain vanilla mxGraph editor looks like:

On the far left a Stencils (Shapes) library or the node objects that you can place, interact and connect, a paint canvas in the middle, and on far-right properties panel for paint canvas or a selected node object. The nodes placed and connected on the layout canvas are rendered as SVG’s but glued in XML file format behind the scenes.

Understanding the mxGraph library structure 🧐

Before taking a giant leap, it was critical to know the exact structure of this library. Several directories and files for canvas editor, stencils (shape) library, interaction, input/output (IO), utilities, as well as how they’re viewed on the canvas. To sum this up check out the tree output:

.
├── editor
├── handler
├── io
├── layout
├── model
├── shape
├── util
├── view
└── mxClient.js11 directories, 143 files

Initialization of mxGraph is done by mxClient.js file which includes all the required factory settings, stencils (shapes), interactions, event listeners, menu items, toolbars and the layout canvas. Scouring through hundreds of files, I got to know the architecture closely. A bulk of components are based on JavaScript prototype object which can be inherited or overridden. Cosmetic changes pretty much depended on how and where to override without messing with the core.

mxGraph vs. VueJS 🤦🏻

Facepalming pretty much tallies my first reaction when reading about the PoC designer requirements. The client was running a Python (Django) application for managing/provisioning of clusters maintained through a registry of vendor, network, and cloud objects. The entire workflow could be condensed in below diagram (made with diagram.io)

While the PoC designer acts as a visual SDN builder tool it still has to consume node objects (Stencils), their default properties, cluster operations that provision, halt, terminate and freeze an instance within the Python API (JSON). Once the cluster design is ready with persistent properties and connectors which can be dynamic, the template is saved in XML format (base64 encoded) using yet another Python API.

A string of herculean labors lied ahead — creating dynamic controls for properties with persistence, event binding, sleek knowledge transfer, and sustainable code base were just a few. VueJS knocks the right symmetry between readable code, plug-and-play architecture, session persistence (data binding through models), more so — no bundler dependencies.

Decoupling mxGraph — first herculean labor 💪🏻

Divide and rule! The science of deduction can’t possibly go wrong, putting this hypothesis to test. Working in god mode 🤞🏻 I decided to decouple mxGraph layout at first. Splitting it with careful incisions, breaking it down to just the layout canvas. The incision lies within the EditorUI.js and Editor.js files (and a few more):

Commenting out got rid-off menus, toolbar, and sidebars. How you include, initialize and override is paramount here. My include hierarchy looks like:

Notice line 97 and 98, that kinda did it 😊. Subsequent steps became clearer, all I had to do is override and include files after mxClient.js, at the most they’re just cloned and/or modified to be retrofitted.

PRO TIP: Don’t mess with the original, even if it’s an 80–90’s song!

To say this was sort-of a hack, but the right one is valid. Minute additions were later introduced for Stencils and Properties using VueJS x-template syntactic sugar. A multi-control component template:

That roughly gave me the power to build dynamic properties with template based syntax, further it allowed dynamic binding with Python API (JSON):

I was able to piece together entire stencils (shapes) library, dynamic node/connector properties with Python API. The default stencils library and node/connector object properties needed advance initialization:

Retrofitting mxGraph with VueJS — second herculean labor 💪🏻

Now that all the bells and whistles are in place, it’s time to roll out the red carpet. Most parts of the mxGraph editor required cosmetic changes (custom stencils and properties sidebar panel) adding up to:

In GIS universe non-spatial attributes refer to extended Geo-location data, identically custom properties are saved inside a <CustomData> XML tag (as JSON), one of the neat features of mxGraph. The graph source XML would look like:

This <CustomData> is also used for VueJS model binding. The conversion between XML and JSON object takes place with a codec. Definition of CustomData(value) codec:

When you click on a node object/connector it gets parsed through the codec returning all the property binding objects for VueJS model. The properties binding part is defined in Properties.js file as:

Putting it all together — third herculean labor 💪🏻

A lot of architectural thinking went into play — it’s no soft-ball, curve-ball or hard-ball, it’s one Atlas stone after another, only strong men may survive. To turn a vanilla diagram component library into a full blown SDN PoC designer took midnight marathons to the final frontier:

Three months of relentless pursuit, few management sparks with casualties — yes I’ve learned to tone it down 😉. As long as client’s are happy, I can live with that. Always is and has been about my developer journey anyways.

References

For a live online demo reach out at: anithegregorian@gmail.com