Comparison of using Ext AJAX calls and using Ext Direct for your data stores

So I had the time and figured I’d try out Ext.Direct and see what happened. A little background on what this is: ExtJS uses the traditional AJAX calls to communicate with the server, and that’s definitely the easiest way to execute calls. The issue comes up when you have a bunch of little calls that need to be executed on page load. For example, on the tool I'm developing I have 16 stores that each make their own call to ColdFusion to populate their data (little things like dropdown stores, and bigger things like stores that are used to populate the actual interface etc). After a certain number of calls that are executed concurrently, the browser itself will STOP making calls so as to not flood the server with hits (essentially stopping itself from being a mini Denial of Service attack). The problem with this is, depending on how many calls you make at once it can take a while to get everything needed back.

So Ext Direct is one method of getting around this. It sets up an API that allows for the database to accept a bundle of calls and then distribute those calls as necessary to the different functions on the server side. Then it bundles those results into one result back to the browser, getting around that browser restriction that they all have. There are other features but that’s the one I’m talking about for the timing breakdowns.

Anywho, I put together some metrics since I compiled everything from my master branch and then a separate compilation for my master-ExtDirect branch. I did a few runs each for refreshing application data (clearing the cache in ColdFusion), and then for just going to the page (no f5, just hitting enter. There is a difference ;)) Also Firebug uses 2 different times. One from total time executing  and another from page hit to ‘onload’ execution,.

Using ExtDirect: Total/Onload

• appRefresh Average: 1063.5ms/937.5ms
• Page Hit Average: 926ms/893.25ms

Regular AJAX calls: Total/Onload

• appRefresh Average: 3200ms/771.33ms
• Page Hit Average: 2770ms/883ms

So what this really says is that the onload times are pretty much the same for each, which makes sense since all you are doing is loading JavaScript files and I already have that compiled in one nice and pretty file (thanks to JSBuilder! But this is actually part of another blog post due to 'issues' around loading of packages and executing the addProvider function). The real benefits show up on the total time. Ext Direct is faster by almost 2 seconds in both scenarios. I know that doesn’t sound like much, but if it’s 2 seconds faster in our closed and ‘perfect scenario’ network, imagine how much faster it can be out there in internet land. Pretty slick stuff ;)

Odd behavior with ExtJS JSB file creation

I was compiling one of our projects to get it ready for an updated release and ran into an odd issue. Everything looked good on initial load but the page started throwing errors pretty much immediately. So I started digging around and saw that the JSB file that previously worked fine was only outputting 3 stores and their associated models. Whaa?

Turns out the developer had put a stores property with those 3 stores in the application definition function. It worked fine when loading everything 'manually' but when it came to the compile process it saw that stores property and apparently just STOPPED. Very weird.

So to fix it I just moved the stores definition to the applicable Controller and everything started working again. Very weird behavior but hey at least it was an easy fix (once I knew what the problem was of course!)

ExtJS Socket.io/CF Gateway Code released!

So, very exciting news! I got released to put my code out there as an open source project. I was able to release just about everything I had put together on this. The Socket.io ExtJS 4 connector. The Socket.io ExtJS Grid plugin (to allow your changes to be pushed to all users!) and the ColdFusion Socket.io Gateway (including SSL support thankyouverymuch). Very exciting stuff. You can check them out at: https://github.com/softwarezman and let me know what you think! I'm open to any/all suggestions so please provide feedback!

Functional ColdFusion Gateway for Socket.IO

So I got my ColdFusion Gateway working pretty nicely with Socket.IO. I have a sample running via Chrome, Firefox, and IE and it's going from the Socket.IO js package on the frontend to the netty-socketio package that I previously mentioned, to the CFC I built, and right back out. I tested it and I can send messages to specific users as well as broadcast to all users. I can send string messages as well as Json objects. Seems to do what I need it to do for now. I broke it out from the original cf-websocket-gateway package that I used as inspiration so that depending on the message type it will call a different function. I really only plan on using the Json message but figured I'd push it a little bit for those who might be interested in other functionality.
Speaking of which, I am trying to get my customer to allow me to release my package as an Open Source project to maintain. It's nothing fancy but I think it would help a number of ColdFusion users out there who want to try some new/cool stuff with WebSocket and Socket.IO. I know I am! My next task is to create a nice and modular ExtJS store plugin that can push store updates to all users who are connected. It would be a useful tool when having a large grid that needs to be refreshed from multiple users (who wants users to overwrite each others' data?) or even chart data like a stock market ticker (note to self, that'd be a perfect example to build!)
So that's my plan. I will try and release what I have to the outside world and I'll continue to develop some additional components to help interface with what I put together. Should be fun! Maybe one day I'll even get users looking at what I've done. Hah. We'll see.

Socket.io, sounds great unless you don't use node.js

So when looking at utilizing WebSockets and all that exciting technology, I was really psyched about using Socket.io due to the fact that it can fail gracefully to other technologies to simulate such communication. Awesome! Except for the fact that Socket.io uses a different protocol when pushing/pulling data that needs your webserver to be customized to support it. Assuming your webserver even supports WebSocket stuff. It just so happens that ColdFusion 9 does not. Of course. So after much searching I found cf-websocket-gateway which seemed like it'd get the job done! It's based on webbit and netty at the moment which seems fine to me. I was able to get the test cases running smoothly but then when I tried using socket.io instead of the included WebSocket piece it freaked out on me (shock of shocks, it requires node.js to work nicely). That's when I found out that it used that super-special protocol to make magic happen. Back to the drawing board.
I have come across a new project called netty-socketio (not to be confused with socket.io-netty). This newer one seems more compatible with the latest Socket.io protocol (.6-0.9.3 at this writing) and is based on netty (which cf-websocket-gateway is based on in a roundabout fashion) but of course does not include the gateway wrapper to integrate with CF 9. So now I can either write the wrapper myself (which doesn't seem so bad, I just haven't used Java in a few years) or just stick with this other WebSocket js package that hasn't been updated in quite a while and I'm pretty sure only uses the Flash fail-over or the browser-based method of WebSocket compatibility.
I think my plan is to write an ExtJS wrapper around this other package with the eventual plan to migrate to Socket.io with this netty-socketio package on the backend. Awesome. The joys of trying new things out but being restricted by your current setup.