Welcome to the Jungle (Redux)

The new Google Chart API says

You can include a Chart API image in a webpage by embedding a URL within an <img> tag. When the webpage is displayed in a browser the Chart API renders the image within the page.

There are some references about how to encode the information in the URLs in javascript. And I was wondering: Can I use it from the server side in my Java applications? Is it difficult? JFreeChart is a good API Chart but it consumes a lot of resources, can I save money in hosting servers delegating the rendering of my charts to Google?

So I wrote this little example about how to use the Google Chart API in Java with the Apache Jakarta Commons HTTP Client. It is very easy, and I wrote a little helper class to avoid the crazy encoding implemented by Google. You can download the source code of the class here. Remember to include these libraries:

• commons-logging.jar
• commons-httpclient-3.1.jar
• commons-codec-1.3.jar

The piece of code to perform the HTTP request is about 20 lines. You need to pass as an argument the parameters at the right hand side of this url

http://chart.apis.google.com/chart?

It returns an array of bytes with the image in PNG format. You only need to push it into the output stream of a servlet, or save it in a file like I do. Ok. here goes the snippet:

private String url_ = "http://chart.apis.google.com/chart?";
private int timeout_ = 30000; // milliseconds

public byte[] create(String postUrl) {

HttpClient client = new HttpClient();
client.setConnectionTimeout(timeout_);

String url = url_ + postUrl;
HttpMethod method = null;

method = new GetMethod(url);
method.setRequestHeader("accept", "image/png");
byte[] image = null;
try {
client.executeMethod(method);
image = method.getResponseBody();
} catch (Exception e) {
e.printStackTrace();
} finally {
method.releaseConnection();
return image;
}
}

The rest of the class includes some helper methods that wraps the crazy encoding made by Google. The reason for this crazy encoding is to avoid the use of POST parameters normally harder to use in the client side. I have coded the class quick and dirt, so if you think it's possible to do it better you are probably right!

I have performed some tests and the latency of the service is excellent: it never took more 2.5 seconds to render a chart, taking from 300ms to 800ms on average. Normally the network latency of Google is very low (less than 100ms), so the time it takes to render a chart is excellent considering this is a very CPU time consuming activity. As a rule of thumb you should cache the requests made to the Google Servers to avoid requesting twice the same chart. You will respect the Terms of the Service (50000 request per day and user, remember!) and your users will be happy because they will get the charts without any delay.

Finally, I think it's worth to use this API instead of JFreeChart if you need to render a lot of charts with a very high granularity that impacts in the performance of your servers.

If you dont' understand why Google is giving for free this API, where is the value of this action, then you probably have never tried to render a chart on the server side. It's one of the most CPU intensive actions a server side solution can have. If you don't size and distruibute your apps properly, your site can colapse with a single impatient user clicking quickly a link several times or reloading a page because it takes more time than usual to render.
A first look at the API shows a very simple API, with a very limited set of functions. The documentation is very oriented to HTML and Javascript developers, but looks easy to implement something in the server side. So think twice before considering changing JFreeChart with this API. Moreover, the number of request per day is 50000 maximum, so if your site has a lot of traffic you will probably need to implement some kind of server side caching strategy. I will make some tests to test the latency of the API, one of the issues with any chart render engine.
Google, now you have started creating APIs for tipically CPU intensive tasks, why don't you try something with PDF and document generation? My Hosting provider will hate you, but my budget on dedicated servers will have a relief!