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?
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: 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.
DZone: What features can we expect in the future?
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?
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 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...