Over a million developers have joined DZone.

mxGraph: A Lightweight Solution for Sharing Diagrams

· Java Zone

Navigate the Maze of the End-User Experience and pick up this APM Essential guide, brought to you in partnership with CA Technologies

While looking for a product that would allow me to create and share diagrams online, I stumbled across mxGraph, an Ajax-based solution that feels like a desktop application. The creators of this application are the same people that have been running the well-known JGraph project. I spoke to David Benson to find out more about his Ajax adventure.

DZone: Could you introduce yourself, your background and your association with mxGraph?

David Benson: I'm David Benson. Together with Gaudenz Alder we have, for the last 7 years developed the JGraph and mxGraph projects. Gaudenz is the main developer, I help with algorithmic sections, and deal with the non-development issues.

DZone: What inspire you to create this project?

David Benson: mxGraph and mxgraph.com were a two-fold process. Back in early 2006 we had only JGraph, an open source graph Java Swing library (diagramming graphs, not charts). Users were just starting to ask for the same functionality in a browser and mxgraph the JavaScript component was born. Initially, it was more of a display component, but over the years has progressed to include a similar level of interaction to that available in the Swing component. It works on over 99% of browsers natively, by usage, using JavaScript combined with the native vector graphics drawing language for the browser used (VML for IE and SVG for more standards-compliant browsers). The component is popular, but we always thought it a shame that you don't see many public web applications developed to be stand alone JavaScript functionality, in the way mxGraph is intended.

The idea for mxgraph.com came through that idea that web applications should be entirely client-side, combined with 3 technologies, 2 of which are recent to the web application scene. The first was mxGraph, which is the only full-client side implementation of it's kind in JavaScript that we know of to date. There are many alternative sites providing diagramming using Flash and the iPad has caused quite an unusual backlash against implementing using Flash we've noticed (unusual in that it's a strong reaction to a device with relatively limited device numbers compared to general use computers). Implementing client-side also gives good scalability, most of the server load is basically delivering the application. Since we wanted to create a site free for all to use, we needed to keep the server load low to reduce costs.

The second technology is cloud computing. We didn't have the people resources to develop the server-side from a basic hosting server, so we turned to the cloud to provide us with hardware that scales on demand. Initially, we looked at Google App Engine, but the black list of Java classes was too restrictive. One thing we needed on the server was image generation and GAE has removed the classes necessary to achieve that. Next we went to Amazon Web Services and were simply stunned by the level of features they offer. With minimal effect mxgraph.com was directed at an AWS load balancer that auto scales server instances by demand. Working with AWS was a real eye-opener to the world of cloud computing.

The third technology is the Google Docs functionality that allows you to access your storage through an API, a feature enabled in early 2010. This might sound like a minor technology, and we haven't switched on the functionality relating to it yet, but we believe this is where cloud storage should head. Web application sites should interface to your personal cloud storage (Google Docs, Dropbox, JungleDisk, etc), not be stored by the web application provider. So in addition to local save/load, we'll soon enable the code to save and load to your Google Docs account, hopefully adding support for a handful of other cloud storage providers later. Anyone thinking about creating an API to abstract the various storage APIs, please do.

This third point is important for two reasons, 1) As a user I'd prefer to hold my own data, even if in a cloud storage environment I want to be my environment, not spread over the 30 web application providers I use, and 2) It means the server doesn't have a database. Why is this important? Because the server is then stateless, there is no interaction between calls or servers. That means the model scales linearly (as long as the load balancer does...). So now we have an ultra-low server load model that scales almost perfectly.

Another thing worth mentioning is the site and domain themselves. It was a very deliberate decision to put one page on the domain, the landing page that is the application, nothing that looks like a web page. You go to the site and the application is there and completely usability straight away. No introduction page with a link to run it. No pop-up when you run the application saying register really quick and we’ll let you use basic features. We’re trying to make something that compares to a desktop application, a lot of sites forget start-up time is a comparison factor. OK, our lack of interest in commercialization allows us to do this, but a lot of what we’re doing here is making statements about what we think web applications should be.

DZone: Can you explain the architecture?

David Benson:


There are three parts. First you have the Amazon servers running Ubuntu and Tomcat, they serve the web page with the JavaScript application. Next there’s the client browser, which does pretty much everything. It’s hard to find much to draw in a sequence diagram since the only communication with the server is to save/load and generate images. We’re developing client-side image and PDF creation to reduce the server load further. That will still require an echo to the server, but bandwidth is far cheaper than CPU.

Lastly, there are the cloud storage providers. Currently, we’re just adding the interface for Google Docs. It would be nice if the JavaScript client could talk directly to Google, but currently there is no library for this, so we do it in Java from the server. As I mentioned, it will be interesting to see whether some kind of common API across cloud storage providers appears, otherwise web applications will start selecting the bigger players and the smaller ones will find themselves unsupported.

DZone: Did you consider using anything other than JavaScript?

David Benson: Yes, but not for long. We're big on open standards and don't like to be dependent on something that just one vendor has control over. Back in 2006 our vector graphics for mxGraph were SVG in Internet Explorer, using the Adobe SVG plug-in. We made the decision that we shouldn't be dependent on the plug-in (and that it should work natively) and re-wrote the IE code to use VML. Adobe pulled the plug-in shortly afterwards, which makes us sound like skilled forward planners, but really we're just old cynics.

We did have a serious look at Flash (http://www.jgraph.com/flash/main.html), but somehow it never sat right with us compared to the open standards that all browsers provide. Flash and AIR seemed to gain traction at one point a few years back, but seems to be drifting away again. As a developer there were a number of things I would have liked to have seen addressed in Flash Builder 4 that were not.

There were other options like GWT, but that adds a lot of server calls that we simply don’t want. It might not make sense to some, but I find GWT a lot harder to understand than simply writing directly in JavaScript. That said, GWT has gained traction, a lot of developers find JavaScript tough compared to standard languages and development environments. The problem is using a tool like GWT you’ll never get the real client-side web applications that people were getting excited about at the start of the web application age. mxgraph.com is very much an exercise in purism in that sense.

DZone: What features can we expect in the future?

David Benson: A great number. JGraphX, the current open source Java Swing version of mxGraph, contains a lot of functionality that mxgraph.com could use. It’s got a pretty complete Visio import, PDF export, SVG export, for example. We have a number of automatic layouting algorithms written in JavaScript that will provide automatic placement for things like workflows and network diagrams. There’s the Google Docs integration and then other cloud storage providers, the main part of the effort there is the visual interface to the files.

In terms of the diagram types themselves, we are going to add contextual behaviour to each one. That is, if you’re creating a BPMN diagram, the option of a swimlane layout will appear on the menu. We’re going to add contextually icons when nodes are selected offering common actions for that type of node in that type of diagram.

We’ve got a great graphics designer on board to produce the icons for the diagram sets. We ran out of idea for him to draw, so any ideas most welcome. One other important feature that we have in the component is collaboration. We have the ability for many users to view 1 diagram at the same time and see changes as they happen. But, this is a very tricky feature for us to enable. Collaboration requires each user to have a hanging XHR request on the server whilst actively working. Suddenly, we have a feature that works against the whole plan of being ultra-low in server load. The Jetty concept of Continuations in the Servlet 3.0 specification is very welcome in reducing memory load for a large number of hanging requests, but still we’d love to be able to offer the feature whilst keeping the site completely free to use. Opera’s concept of a web server built into the browser might help in this regard, but this doesn’t look like an idea that is going to catch on in the near future.

DZone: Is it open source? Or can it be extended? Is there a way to provide additional components?

David Benson: The core JavaScript isn’t open source, it’s a very complex bit of code that I very much doubt would bring in external contributors. I’m a very great believer in Fred Brookes’ surgical team concept, and the way in which Gaudenz is for the main part the sole developer of mxGraph has enabled us to build a very functionally component with a very small footprint. The Java parts of JGraphX used on the server, like Visio import, are open source and we’ll look at whether open sourcing the code exactly as used on the site is useful. But again, there is very little to that code, just 3-4 simple servlet methods.

What people are really interested in when they say they want open source is to use the code for free really. What we’re looking at there is a model similar to Google Maps, where an API key enables usage in personal applications. We’re also thinking about ways for people to use virtual instances of the diagramming app and enabling embedding in other web sites, but that isn’t for the short term.

Extensions of mxgraph.com would involve either supporting new features or adding new diagram types. There is a hoard of features planned, users are always welcome to suggest them at http://mxgraph.uservoice.com/forums/68883-mxgraph-com . The same applies for new diagrams type, we’d rather improve the web site centrally to start with before thinking about ways to allow niche extensions to be created. In terms of new diagram types, again, we’d prefer to implement these based on user requests rather than accepting submissions. I mentioned a great graphics guy we have doing the icons, as much as anything I’d prefer all the graphics done in his style.

 mxgraph.com is more of a pet project of ours than a commercial idea or open source project. We’re trying to prove a number of things:

  • That you can create complex web applications that are virtually entirely client-side in JavaScript without the use of web application frameworks that translate to JS.
  • That you can create these applications to provide similar functionality to the desktop equivalent using open standard technologies to make it available to pretty much every browser in existence.
  • That cloud storage should be done using personal cloud storage providers, not with the web application provider. I firmly believe that this is the model that users would prefer, but web application providers will resist for commerical reasons.
  • That Fred Brookes is right...

Thrive in the application economy with an APM model that is strategic. Be E.P.I.C. with CA APM.  Brought to you in partnership with CA Technologies.


The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}