The Local JavaScript API for Local People

I was giving a presentation at an ESRI gathering hosted in reading at Microsoft this week, talking about all things Silverlight and MapIt, and very little unsurprisingly about the Flex API. During a presentation imageabout the Web API’s I mentioned JavaScript and Silverlight as two offerings that whilst can do similar things, need to be considered carefully in relation to the audience in questioning and the tasks they wish to perform. Now I like the Silverlight API and as I mentioned in the talk it can really allow for the avoidance of browser support pain by abstracting away the layer between your application  and the browser hosting it.

Often though you don’t want a plug-in to preclude people accessing your site, this might be down to a number of reasons but unless your going to start hand cranking simple code for map access (people who have to disable JavaScript within your browser should stop reading now) then you have the JavaScript API. Usually this is delivered to you from somewhere in the cloud ( specifically), but often there are a number of scenarios that might occur that will mean you have to install it locally.

Why Local?

If you are an ArcGIS server subscriber you are able to request the JavaScript API from ESRI or your local imagedistributor as explained here on the support site. There are a number of reasons why you might wish to do this:

You are super secure and think that access to the internet is a potential security risk  and therefore getting access to the online API is not possible. Many organisations have yet to embrace the concept of Content Delivery Networks (CDN’s), such as that used for hosting the ESRI JavaScript API. Whilst in a consumer space this is a common architectural practice as it places the download on the users connection for the CDN and not on the hosts (saving bandwidth allowing that to be used for serving images and functionality). Often within the firewall of organisations it is not possible to access external files as the network is secure.  This is also the case where you have a slow external connection and you wish to limit the amount of information that is downloaded from the ‘cloud’.

imageYou want to create a custom build of the API to reduce the number of files downloaded, improving browser response. The classic number one rule from High Performance Web Sites of making fewer HTTP  requests asks for front end developers to minimise the number of files they download from a site, when building on top of the JavaScript API it is common to build your application into many separate files to separate functionality or Dijits and to allow the usual spaghetti of development that can happen with JavaScript to be controlled.

A concurrent dilemma

The problem with this is that each JavaScript library you add to the application the longer it will take to download due to the limited number of concurrent files a browser can download at once. This is the same if you include new CSS files and images as well. This is down to the way HTTP 1.1 was implemented and setting a limit of no more than two files concurrently per hostname. BrowserScope explains it nicely as:

When HTTP/1.1 was introduced with persistent connections enabled by default, the suggestion was that browsers open only two connections per hostname. Pages that had 10 or 20 resources served from a single hostname loaded slowly because the resources were downloaded two-at-a-time. Browsers have been increasing the number of connections opened per hostname, for example, IE went from 2 in IE7 to 6 in IE8.

image This often leads to developers hosting parts of their application on different hostnames one starting with a URL such as and another such as, to get around such limitations. With large JavaScript libraries the time it takes to download these on slower connections can leave an application imageunresponsive and give a very bad user experience.

You can see from their tests (see image left) that modern browsers have upped this limit to 8 connections, this can have a dramatic affect on perceived speed as more of the application can be downloaded at once and when partitioned correctly (using a lazy loading pattern preferably) then users can see something happening in the browser much earlier than they could with a plug-in such as Silverlight or Flash (beware the loading circle of doom).

Of course with external (public facing) applications you will always have some users using IE6 and the limitations of 2 connections per hostname. This is where the ability to package your JavaScript files up into as small package as possible and as few packages as possible becomes more important and the need for a copy of the local JavaScript API imperative for use in a custom Dojo build.image

One build for all?

Unfortunately each build is different for each project and therefore there is no magic bullet for this. Fortunately there are a number of key pieces of information and discussions about how to perform this task. There is a thread on the ESRI support forums going through the process an excellent Geocortex post upon why they did a custom build here and finally a link to the Dojo documentation outlining the process in full. Whilst it might be a complex procedure, for people who are interesting in getting their application to load in the fastest time within the browser, it should be a procedure worth looking at.

IE 6, 7 and 8 and other browsers. Support them all.

As you can see I’m not one for short posts, but sometimes a great article needs to be pimped. Smashing imageMagazine has lots of those and whilst I’m mostly a Web Developer and not a Web Designer (I do have an iPhone so there may be hope for me) it’s good to keep an eye on the current design trends for web applications.

Smashing, super, great, well not so great with IE6.

Their current article “CSS Differences in Internet Explorer 6, 7 and 8” is a change from the normal rant at Microsoft fare, but aims at understanding all the differences that occur in the Microsoft browser segment of the market around, in this case, their different handling of CSS. The main fact of importance is the imagecontinuing need to support all of the browser due to their market share, each browser holds almost an equal share of the 65%+ of the market (as seen on Market Share).

In fact if you break it down even more we see that IE8 compatibility mode beats Chrome and that really for public sites you should be testing for Safari as well.

Browser Market Share
Microsoft Internet Explorer 6.0 24.42%
Microsoft Internet Explorer 7.0 19.39%
Microsoft Internet Explorer 8.0 16.84%
Firefox 3.5 12.65%
Firefox 3.0 9.62%
Safari 4 2.92%
Microsoft Internet Explorer 8.0 (Compatibility) 2.30%
Chrome 2.0 1.74%

Like any large company, Microsoft has a great deal of legacy to support, people who have brought their products, people unlike myself who don’t want to upgrade at the first opportunity, who are happy with the way something works (even if it is IE6). Especially where a browser still holds such a large part of the market within the enterprise space, the cost to upgrade all of the browsers (which work for all the applications they currently use by the way!) could be prohibitive in the current economic climate.

Testing Painimage

All this leaves is a massive amount of legacy testing pain for development teams, especially when developing applications for use within an enterprise environment. It’s all very well for people on the social side of web development to trumpet the call to the new, but when part of your market is stuck in 2001, so to a certain extent are you.

At this point it’s interesting to look at the support level of browser for ArcGIS Server here. The supported browsers are Firefox 2,3 and IE 6,7,8. That’s not to say stuff won’t work in Chrome (it’s does, I’ve tested it) or Opera (I don’t know, sorry), but the official line is what is shown on the site, so when developing applications for use with ArcGIS Server it’s always good to remember what’s official supported and choose that as a baseline.

In fact many people are tempted to throw the browser out completely and fall back into the loving arms of the plug-in. Flash and Silverlight take much of the worry about browser support of the nuances of CSS imageand JavaScript but providing a nice sandbox for the application to play in. Unfortunately they are no true panacea. Often the enterprises that are still on IE6 are probably on Flash 5, if they have Flash at all and might never have considered Silverlight (although Microsoft’s positioning gives Silverlight a more enterprise-y feel allowing it to make inroads sooner within the firewall). This leaves you back at the beginning needing to support your browser based application in IE6, there is no escape, accept it and test accordingly.

And finally.

One great quote from the comments is this “You could power every house on Earth for a few hours– just from the sheer RAGE MSIE elicits from Web Designers.”. It’s not just IE, the lack of standards amongst browser has always been a frustration, Microsoft might be the current football to be kicked around, but in its day Netscape was the villain. image

Whilst most people, probably even Microsoft, want IE6 to go away, it wont soon, people image like have a funny campaign, but the only thing that will change that is when all the big companies have gone through a technology refresh and the
re are only a few copies of IE6 lingering left. In the non-corporate world, well as Amy Barzdukas (Microsoft IE general manager) says "Friends do not let friends use IE6”.

Do you Cache?

Before you read on this isn’t a post devoted to image caching. This is a post about data caching in general imagewith image caching being an extreme form of data caching. It comes from a bit of work I did recently caching data from a tracking feed. It’s based around why you want to cache, what data you might need to cache and how you might cache (I used .NET but you can do it in all major web development languages). Caching has often been the premise of web sites that want to be, and I’m using a technical terms here, ‘screamingly fast’ and not ‘snail slow’.

Caching before caching was famous.

For many people developing with ArcGIS server caching means one thing, map caching. This has imagebecome the panacea for many scalability issues with applications. As if the maps are going to be the only slow part of your application. Whilst removing the bottlenecks of pretty maps away from your site is very important it often can form one part of your data caching strategy. There are often other areas that you might look at when deciding what to cache and when.

In web applications caching can occur in at a number of levels, specifically at the data level (caching data to avoid making costly requests) or the page output level (caching the output of web pages so they don’t have to be built in real time every time). Combining these areas can help an application scale but there are a number of considerations you should take into consideration before implementing any caching into any system.

Often with spatial systems, especially in the enterprise (within the firewall) the need for data to be current often outweighs the extra benefits that might be gained through getting a few more users onto the system. The difficulty is understanding with any application is how much it will scale and whether imagebuilding this stuff into the project is worth it, the problem is that usually when you realise that it might be useful it’s too late to refactor your application and you’re stuck in a world of application fail. Now it’s easy to crow at the big internet applications when you see they are struggling with the amount of users on the system, most of us though will never have the same architectural issues that plague Twitter, Flickr or Facebook, if you do I suggest having a read of the Art of Capacity Planning to understand how to monitor the load you’re going to be under and to mitigate appropriately!

For the rest of us it shouldn’t mean that the use of caching won’t help our applications, even under modest scale and if you’re a .NET developer there are easy ways to implement it within the system, either at the code level (for data caching) or the server level (for output caching).

So what does to cache mean?

The process of caching is basically the storage of the output of a request or set of processing; so that once it has been done it may be reused for a number of people. The basic premise being that the output imageof the work is valid for a number of users and any changes to the underlying data will not impact the usage of the information within the time period that the cache is valid. This means that you need to understand the nature of the data and how it is used within any workflow. Failure to do so can mean your users potentially seeing data that is temporally incorrect, something that wouldn’t possibly be out of place in a episode of Doctor Who. So the two main questions with caching are the concepts of what to cache and how long the data can be validly stored within the cache.

What to cache?

The question of what to cache is always going to be a tricky one that will be down to the application that imageis being developed, down to the need for currency of the data being used. If you think that data can be delayed 15, 30 or 60 minutes, or even longer, without affecting the users operation of the site then it’s probably ready for caching. This could save endless requests for the same data that in turn reduces the processing cycles on your servers, reducing the number of machines you need to use thereby reducing the cost of the implementation. Even in this world of unlimited cloud machines, there is still a cost associated with every processing cycle and every saved resource is saved money, again good in these times of thrift.

In terms of exactly what to cache these three areas given by Microsoft in their enterprise caching block information are a good start:

  • You must repeatedly access static data or data that rarely changes.
  • Data access is expensive in terms of creation, access, or transportation.
  • Data must always be available, even when the source, such as a server, is not available.
  • imageIn order to make your site as robust as possible you need to take a pessimistic view of software and servers (no comments please) and admit that at some time they will fail. If you want to protect yourself from such failure using a cache to store data and to make sure it never expires if you don’t get new information will allow your site to give the impression that it’s bullet-proof even though things are blowing up at the back end!

    How to cache?

    Microsoft make it amazingly straight forward to implement data caching, although as I said deciding what to cache and for
    how long is another matter. On the web there are ways of adding to the data cache of an application using the HttpRuntime.Cache property that can be used to get access to the applications cache. The report manager example given on this MSDN page gives a starting point for implementing a class that can control access to a piece of cached information.

    There are a number of choices that need to be made whilst using the cache object. Especially around the timing of objects, an absolute or sliding scale can be used to control how long an item stays in the cache. Long running static objects that don’t change can be kept alive using the sliding scale, as long as they are accessed within a time period they stay alive. Objects that need to be updated periodically can be made to expire at a certain time so as to make sure they are current to users but also to not require the server to process to much or request data from remote services too often. Further information about caching and ASP.NET can be found here.

    Timing the Updates

    Have a look at this picture. You can see the red line, which is the route the person is riding. You can see imagethe person, WTF? I hear you say… well maybe not. But it shows a good point about getting the timing right with any bit of cached data. Here we have two cached pieces of information. The position and the route. We get both in WGS 84 and want to project them into Web Mercator to lie over our map tiles.

    The point request can be performed very quickly but might not get updated very often; the route get’s updated even less but can take longer to project. We can see that if we update the position every 15 minutes, which is quiet timely enough when tracking someone on a bike, and the route every hour say, which again should be fine, then the application should be able to scale quiet well as the amount of requests we are actually making is quiet low. Why the problem?

    Well obviously there may be a point whereby the position is not updated in the cache between the time that the the route is updated and the position is updated. This might be because the feed you are using image(if it’s not your own) in turn is updated at different intervals. In the picture (at the start) we have the rider’s position slightly to the left of the end of the route as the caches are slightly out of sync. Five minutes later and the rider is back where they should be (and the corresponding rift in the space time continuum is closed, phew!), as shown in the picture to the right.

    This raises an interesting point about how to time your cache. Do you have one cache for everything; do you cache various pieces of data at different rates depending upon how often the information get’s updated?

    Do I need to care for my application?

    As with any architectural decision within your application the need to use caching or not should be down to the actual amount of users you are going to get and the complexity of service calls you’re going to make. imageOften though it’s the unknown unknowns that with affect the application over its lifecycle that will make the difference, will someone decide to roll your nice heavy weight intranet application out over the internet (it’s happened I’ve seen it, it wasn’t pretty)? Will your obscure application suddenly be tweeted about by Stephen Fry (he loves to watch websites die!)?

    There are many issues whereby having an understanding of the use of caching might be important, and in fact site saving! With the ease of implementation with today’s tools then there is little reason, apart from ignorance (usually mine…), whilst a certain level of caching can’t be built into even the most innocuous application.

    Cycling to the Ashes

    For me getting back into caching was all about developing a simple website for a charity bike ride for the ashes. Anyway whilst it might seem a different world from what we usually do at ESRI(UK) the actual scalability challenges that might be found in a consumer application that might be mentioned on a national radio or television show (or even by Mr Fry!) are the same in a large enterprise application and if designed correctly should be able to scale appropriately.

    If you’re interested the application can be seen here at CyclingToTheAshes or as a bigger version here MapsPerSecond. Whilst it’s a simple application, and for those who care it was built using ASP.NET and the ESRI JavaScript API using OpenStreetMap data, the challenges of scalability and robustness needed to be met due to the nature of how the site was being marketed. There were also long expensive calls to the REST services providing the location (from Sanoodi) and project the data (ArcGIS Server), both of which needed to be reduced where possible through caching!

    Anyway if you have read this far and are still awake (once again this post wasn’t meant to be so long!), please hop over to Oli’s site and go sponsor him, it’s a worthy cause.


    Where are you from? A journey into WCF with Dojo.

    To celebrate the upgrading of the JavaScript API to 1.5 I decided to have a little play with adding a where are you from page to the site (you can get too it from the page link above). This is a little routine to take your IP address and geo-locate where you are. It’s a very simple application in the style of Al Pascual’s imageMap Stats Silverlight application that you can get here. In fact it’s almost the same, except it works with Dojo uses a different IP geolocator from IPInfoDB as the one used by Al didn’t know places like New Zealand existed.

    It was an interesting application to write, not only did it let me get acquainted again with the JS API, but also accessing simple WCF services from Dojo (easier than you might think) and working with the .NET JSON data contract serializer’s. Once you have the basics of those then the world is your oyster in terms of getting functionality into the browser. The Dojo bits were easy, a few bits of JavaScript on the page a call to a service using xhrGet and were cooking on gas, all we need now is the working WCF service. Hmm now that should be easy yes?

    WCF Learning Pains

    I’ve always been amazed about how Microsoft took a nice simple thing such as Web Services and made it so much harder with WCF. I do understand that you can to so much more, but with the Visual Studio IDE imageyou just used the template to create the webservice (add new!) and there it was, easy as the proverbial pie. Now with WCF it’s all about message contracts and whether they right information has been dumped into your web.config file. Now I do understand the power of data contracts and how they can be extremely powerful, but the fact that after creating a new WCF service, I had to make sure everything was decorated correctly down to specifying the right binding on my endpoint (if you don’t know what I mean then don’t worry it’s not really worth knowing, if you do I think you should get out more). Why do I have to do this? I think I’ve become lazy when developing with Microsoft products, when the tools fail me I have to start relying on my brain again (ok I use Google’s brain, but haven’t we all outsourced our thinking to Google already?), I think I last used that was when I was developing Java applications (or come to think of it debugging JavaScript!). So my new checklist for getting WCF services ready to be used with Dojo is:

    • Is your endpoints binding set to webHttpBinding in your web.config, mine wasn’t it caused me grief.
    • Have you set your AspNetCompatibilityRequirements to allowed in your service attributes? I think this matters, stuff works once it’s been added in (lots more info about WCF and ASP.NET can be gained here, a must read).
    • Does your operating contract (contained in your interface file if you didn’t know) specify the right parameter names for the Dojo request (mine didn’t it took me a while to realise why nothing was actually being passed in, classic brain-fail!). image
      Now I can actually see that these things are going to help me in the long run, I just wished that stuff I could have knocked up in about 5 minutes in the old way takes me so much longer and a great deal more fiddling to do. It’s like having to do real coding again, not just concerning myself with actually getting the applications to do what the customer wants, yeah I remember those days, they weren’t good in my opinion!

    serviceHostingEnvironment what’s this then?

    Once I had the code working there was one final journey into the unknown depths of the servicemodel section of the web.config file. This had to do with deploying my application onto my host, which has a number of URL’s that are assigned to my domain. This confuses WCF and gives a strange error when it cannot seem to resolve the correct one. So it was back to the web.config file to set the baseAddressPrefixFilters element within the serviceHostingEnvironment tag. Fortunatley my Googlebrain was able to help me out again and I managed to find this post (ironically from my host!) although the simple solution is contained in the comments.

    I am not Spock.

    Yeah I know you think I’m making it all up, I wish I was. When designing this stuff they should have read Jol Spolsky’s duct tape programmer post to understand whilst many people can get software to work and be delivered on time, were not all Spock.  Nor do we wish to devote out life to being Spock, I have games to play and wine to drink (and if I have any time left over a family to be with, well maybe I can spend a little more time coding!).

    Anyway after all this I managed to get my simple, yeah it’s not very complicated once this bits fall into place, location application working. I’ve got a few more plans for it (integration with Firefox location, addition of Tweets in your area, <insert additional social API integration here>, you get the idea.

    Once complete I’ll post some of the code up and if your really interested, sometime I’ll go through how I wrote a WCF class to consume the ArcGIS Server REST API, yeah I know you can’t wait. In the meantime I’ll put the existing code up soon but head over to the page to find out where you are (if you don’t already know!) and remember as you develop all this ninja code the following adage…