Wednesday, 2 December 2009

JavaFX vs GWT - A developer dilemma in building a RIA application

For the past few days, I have been working on a simple proof of concept; a web based stock streaming application with a community theme to it. I set myself to building the backend first. As you can guess, I am developing in Java and here are some of the requirements that I have to meet, at least:

  1. The application shall allow the user to query a stock (quotes) either using the stock ticker or the company name and display the following: stream stock price with basic info, stock historical price; tabular view and financial chart analysis.
  2. The ability to rate, comments and share stock information.
  3. provide a real-time chat features for users of the application to interact together.
  4. single sign-on integration with OpenSocial, OpenID and Facebook connect.
The above are some basic features in order for people to actually use the site. As you can see, they are mostly front-end requirements. Here is another important requirement:
  • The application will be hosted on a Cloud-based service, the application shall keep to a minimum the load on the server as CPU and memory use will be charged per request.
I believe that last requirement was the key decision factor. I needed something that will make use of the user resources instead of stressing the server. Something that would execute on the browser, client-side. Being a Java developer, it is only normal for me to look for something that I can grasp easily and freely available on the market. I looked at a few RIA frameworks and tools but I needed something that can integrate within my development environment without the need switch between IDEs.

I had a look at JavaFX and GWT. Having worked on GWT in the past, I found that I could implement most of the requirements. GWT has a rich api and components sets (widgets). I could use the Google search, map, visualization... to build the front-end and implement the client side code.

It took me about two days to implement the basic front-end and back-end features; mostly concentrating requirements 1 and the last. But then I hit a brick wall, something that all Javascript developers already knew but I just came across:

The application is a mashup of different services from around the net. Some of those services were available for free and others were not available at all but I will still be connecting and parsing the relevant data to displayed on the screen. As requirement "1" was working fine, there was a disaster about to happen. Here is the basic architecture:
  • when a user queries a stock, the data is sent to the back-end services.
  • the back-end services queries a third-party web service which I do not have control over. ZERO.
  • when the third-party web service returns, the data is then parsed into a format understood by the front-end and sent to the front-end services to display. 
The services was working fine until I had about 12 stocks displayed on my screen for testing purpose. The data was being streamed with a 1 minute interval. After about 30minutes later (and 360 requests = 12 *1 pm * 36m), I have noticed that the stock data was not being updated anymore and some screens were blank. No errors were logged and some other queries were still working such as the historical data. As I could not see the errrors from my debugging session, I therefore decided to query the third-party service manually through Firefox and IE and VOILA! The service provider had put a temporary ban on my IP address for making too many requests, it says. This was a major blocker as it seems that I could not access my primary data anymore. This left me questioning the feasibility of the project.
If a single user gets banned for tracking 12 stocks, what would happen when 100 or more users start watching their stocks?
OK, so I did not give up, at least not without a fight!

I looked at the problem from another perspective, the third-party view. How do they track my request as I do not have to register or sign-in? The obvious answer is my IP. So I thought, instead of making the request to their services from the back-end, I should send the request directly from the front-end. If each users make the same request, the third-party services would register different IP addresses for each one of them. Correct indeed but one big problem:

The front-end code is written in GWT which is then compiled to Javascript. Being a Java developer, I was not aware of the limitation of using AJAX in a mashup such as mine. After making the necessary changes, I then run the app just to get hit with another blocker - SOP (Javascript Same Origin Policy). What's in a monkey name was this all about? So after researching it - Google and Wikipedia, I knew what I was dealing with and I am sure all Javascript developers already knew that but not me :(. I never give up, it is not part of my nature, therefore I decided to look for ways around it and came across a tutorial on GWT site that shows you how to implement a workaround. Did the tutorial, implemented some basic methods and that worked fine but implementing the third-party service, did not work :(. The problem was simple, the workaround needs to be in JSON format which I coded but the third-party service needs to be able to send the request back to a "callback" method. This is it!!! Remember that I mentioned that I had ZERO control over the thrid-party service and therefore I could not implement this feature.

Remember, I never give up; when there's a will there's a way. So I hit a major blocker due to the technology, in this case it was Javascript. I know that if I was working on a pure java front-end GUI, this would have never occurred and Flex allows you to query other third-party services but I have no knowledge of ActionScript. I decided to go for JavaFX just because it is Java and allows me to connect and get my data (actually it's not mine). My options were Webstart, Applet and JavaFX. First of all, it has to be part of the site so my real options were Applet and JavaFX. Applet do not have a rich set of tools such as Map, Chart and everything else that JavaFX provides and I do not want to waste time coding them.

So same adventure but different episode; I am currently looking to implement the JavaFX UI so stay tune for the sequel and screenshot. I could have never anticipated those problems with the third-party and then Javascript but believe me it was a good experience and my Javascript just went +1.





9 comments:

  1. JavaFX is an expressive client platform for creating and delivering rich Internet experiences across all screens of your life. It combines the best capabilities of the Java platform with comprehensive, immersive media functionality into an intuitive and comprehensive, one-stop development environment.

    vitamin e

    ReplyDelete
  2. For heavy GUI development is Adobe Flex also a good decision. You can easily create good looking charts with a low effort. You can connect the Client with Servlet or SOAP calls to the backend. Learning ActionScript is very easy for Java Developers. Take a look at this Flex-Example, impressive isn't it?

    http://examples.adobe.com/flex3/devnet/dashboard/main.html

    ReplyDelete
  3. @Siegfried, you are right about Adobe and the demo is very impressive. I also like the fact that there's no security pop-up to scare the user as with Java applets. But people are used to the applets security as it's used in Facebook and Twitter (just two examples). A feature of JavaFX that looks very interesting is the fact that I can drag the app out of the web. Brilliant!!! So it can be both a web and standalone app. I still believe that Adobe has a larger selection of components available butI need to give JavaFX a try, but thanks for the comment.

    ReplyDelete
  4. A while back I evaluated JavaFX, Flex, and various JavaScript based frameworks including ExtJS and SmartClient. Flex was the winner for develop productivity, its ability to produce an RIA type interface, and for the Flash player's ubiquity on existing desktops (98%). JavaFX suffers from a much lower install base and requires a very recent JVM to run it. ExtJS and SmartClient were very powerful toolkits but seemed to require a lot of hand coding of JavaScript code in order to do anything "real". In my opinion, if your users are OK with the Flash 9 or higher plugin requirement, Flex is the best choice.

    ReplyDelete
  5. Really like your blog content the way you put up the things…I’ve read the topic with great interest and definitely will stick your blog routinely for other great posts. http://scarprin.info/

    ReplyDelete
  6. Thank you for this valuable information, I hope it is okay that I bookmarked your website for further references.

    ReplyDelete
  7. I was very pleased to find this site. I wanted to thank you for this unique read. I definitely savoured all bits and pieces of it including all the comments and I have added you to my bookmark list to check out new articles you post.
    www.fadeplex.com

    ReplyDelete
  8. A very informative article and lots of really honest and forthright comments made! This certainly got me thinking a lot about this issue so thanks a lot for posting!
    San Antonio House Buyer

    ReplyDelete