Interface Design: Serializing Java Graphics to D3.js [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

I'm currently in a debate at my workplace about the design of an interface between a legacy Java Swing application and eventual output of d3.js graphs. The current application is a desktop statistical exploration tool that parses data and outputs graphs using Java2d. The application is being converted to a server/client application with a web frontend.

Currently the graph logic is tightly coupled with the Java2d code. While technically an implementation of Wilkonson's Grammar of Graphics, each component in the graph's tree renders out to a java component.

I'm proposing refactoring the graph system to output a structured spec for the graph (json, xml, whatever), which can then be passed on to the consumer (front-end web, ipad, etc) for actual parsing and rendering. This would decouple the graph structure from the actual rendering, theoretically allowing the same output/blueprint to be used for in any client side library or rendering format, be it d3.js, three.js, svg/canvas/webgl, or even native code.

This seems to make intuitive sense to me, but my coworkers are very much against the idea. Instead they suggest tweaking the system to generate d3 javascript code on the server side, which the client will then consume directly. This would require implementing all graph setup code on a per-graph basis (theoretically using some template engine to conditionally include js in resultant html). Our resulting would be directly tied to d3 itself. They say the upside is that the client wouldn't have to do anything to render the graph output.

Am I missing something here? Is the latter approach somehow more desirable in the long run? Or am I on the right track with the former design? Are there some benefits I should be considering in the generative javascript approach? Alternatively, how should I structure my argument, in favor of a serialized graphic spec, in order to get more people on board with my design?

Answer 1

With my limited knowledge as a given, your solution seems to be more generic. Can't you do yours and then run a client locally and grab the D3 JavaScript and output that to the server? I.e., do both in series, with the initial output from your approach as an intermediate stage.

Additional development time may be why they are making their suggestion, so you may have to be able to prove that this won't take you much longer and will provide added benefit.

Answer 2

While either solution could indeed work, I'm not sure I see any benefits in producing D3 graphs server-side and then sending them to the client.

On the other hand, by doing so I can see a number of side-effects to this approach such as:

• Even stronger coupling for no performance improvement -- can lead to brittle code & unintended consequences
• Lack of flexibility to support other clients that may take advantage of your graph data but don't support D3 or Javascript.

Answer 3

So basically it sounds like you're considering an abstraction layer to simplify output of non-D3 formats. If that's the case, then the value of such a layer depends heavily on your expectations for the future of this code.

If you know you're going to be implementing non-D3 solutions in the future, then it makes sense to separate the general purpose "chart" logic from the specific "D3 chart" logic, since the two operate independently of each other.

On the other hand, if you suspect you might someday implement a non-D3 version, but have no immediate plans to, then I'd think the YAGNI (you ain't going to need it) principle applies. In other words, you should code whatever is best for the task at hand (ie. no abstraction layer) and then refactor one out whenever it actually comes time to implement a non-D3 chart.