I am developing a graph-editor that uses drag and drop to build hierarchical graphs (containing nodes and links). Each node in the graph should be linked to a table in our database (SQL Server). I did a lot of research about libraries based on javascript or/and JSON specifications to draw nodes and links. There are a lot of great examples to follow, but I have no idea about the way I can link a graph to a database (SQL Server, Oracle, MySQL…). I thought about this architecture (Question posted on stackexchange.com)
I have looked at the D3 library. It creates data-driven charts, but I think it only uses flat files, and not relational databases.
First can you please tell me if my architecture is well thought out? And second can you give me some ideas about the way I can link my graphs to the DBMS? Thanks a lot.
D3 is a great library, whose pretty clever design is the result of many years of research. It is the descendant of Protovis, a library that was already very nice at its time. Then the author, Mike Bostock, moved on to something more dynamic (differences are outlined here).
There is a fair amount of weirdness at first sight in D3. The ways you bind visual elements to the data, respond to changes, update the graphs, etc. may not seem intuitive at first. But after a few experiments, following the numerous tutorials and reading the extensive documentation, you become quite productive.
In a first order approximation, you can think of D3 as an SVG canvas. It allows you to create and manipulate, not unlike jQuery, the SVG DOM in an efficient, cross-browser manner. Then realize you can, instead of manually creating SVG nodes, define systematic (i.e. declarative) mappings from data to visual elements. On top of that, D3 allows you do customize, animate, let the user interact with the graph – and many more things.
Regarding your question about the architecture, I think the SO question you link to answers most of it. Yes, it is sound, and it is the way to go if you want to pull your data from a RDMS.
The way we usually design D3 apps is the following:
- assume your application is going to eat JSON data – you can always turn other formats to JSON on the server-side, and JSON is much more flexible than all other formats (except perhaps XML but once you’ve tried to
json_encode()a PHP array, you never look back). - create a static
index.htmlfile, putting the necessary boostrapping code in a companionapp.jsfile (and a maybe a CSS – the usual stuff). You may want to use one of the examples as a starting point. - create a static
data.jsonfile in the exact format you expect the server to send your data. Put some sample data inside. You can also put this JSON data directly inside yourapp.jsscript – JSON is Javascript after all. - work on your frontend logic, refine the JSON data format, etc. until you have a decent prototype.
- setup a simple web server (e.g. Apache), have it serve the JSON file, and make your prototype work with this instead of the local file
- create a server-side script that generate the same “static” file (e.g. using PHP). Test your app.
- have the PHP script connect to the database, generate the JSON file on the fly and send it
Now you can work on improving the application: defining different URLs to pull different data streams, create means for the user to filter the data, etc.
These are just ideas to get started. The point here is to minimize the amount of changes between each step, so you learn things one by one, and keep focused on the parts that are really difficult: the client application. Binding to a server that generates real-time data is just a step forward once you have a good app.