OpenSocial: A Beautiful Platform for Server-less Web Development

It’s belatedly dawned on me how OpenSocial makes a great server-less Ajax platform. When you create an OpenSocial gadget, you’re building a lil Ajax app that performs much coolness that would normally require a server, but doesn’t. Effectively, you’re delegating the duties of the gadget’s host environment. All you have to do is write a single XML file and host it somewhere. In fact Google Gadget Editor gives you an editor to write it in and a place to host it.

In fact, this is so good that if I was teaching someone Ajax in 60 minutes or less, I would consider getting them to write a gadget. It’s that simple. Previously, I might have got them to write a static HTML file, with embedded Javascript and CSS, but now they can do the same thing and benefit from server-side features too, features they never had to install. This is like getting the usual benefits of the DOM and the Javascript API, but with much more. You’re getting both a set of APIs, just like when you use JQuery or Prototype, but you’re also getting a server which many of those APIs rely on. So it’s a true platform.

By the way, I’m assuming you’re using XML content type, not URL. XML content type is the way forward, especially as we move to a Caja world. XML gadgets will get you the richest functionality. URL gadgets are only suitable for legacy concerns, and in some cases, accessibility.

So you’re using XML content type, which means the entirety of your Ajax app lives in one file. What does an OpenSocial platform provide to your little XML gadget spec?

  • Persistence. The most important thing is you can save application data. You can serialise any state you care to persist, and then store it as a hidden user preference. This is really neat. It means you can write a TODO gadget, for example, and ensure all the TODO tasks will be saved, but without having to store them on your own database and without having to build a persistence layer around it. And of course, the platform will (theoretically) provide the necessary security to ensure users only see their own tasks.
  • Preferences. You can easily let users customise your app via the preference API. For free, you get form fields to let users state their preferences, with drop-downs for enumerated types. And of course, the preferences are persisted without any effort on your part.
  • Content Fetching. It gets even better. On-Demand Javascript is often bigged up as the way to get data from third parties. But thanks to OpenSocial’s remote fetching APIs, it’s just as easy to grab content via the containers Cross-Domain Proxy. This means you can get any internet content and call any API, not just those specifically designed for cross-domain browser calls. There are also value-adds here, e.g. caching, scheduling periodic updates, converting feed data of any format into a consistent JSON structure.
  • Identity and Social Networking. Ah yes, the almighty “social” in OpenSocial. On the right platform, your server-less Ajax app can get info about the page owner and the page viewer, and their friends. Friends and social stuff and knowing whose page it is, that’s cool and all. But what’s really exciting here is much simpler than that – it’s simply IDENTITY. What matters most is: With a single API call, you get an ID for the guy viewing your gadget!!! You didn’t have to handle registration, password reminder links, etc. etc., and go through all the associated security questions around it. All the usual stuff you have to do if you want to know who’s using your application. It’s all *free* to you, gadget developer. (Downside is your company doesn’t “own the user”, so your gadget will never get you pina coladas on the beach at noon and an environmentally-conscious hybrid vehicle to sip frappachino grandès in.) With this user handle, you can also save a hashmap of information about the user, persisted by our friend the server.
  • Many other services. Each platform is free to provide any number of features beyond the required API; this is how platforms compete against each other in the OpenSocial world. “Feature” is actually the term used for a particular set of browser and server services, e.g. “dynamic height” – the ability for a gadget to update its height – is a standard OpenSocial feature. Notifications – the ability for gadgets to add little notes to the top which the user must manually clear – well, that’s a custom feature iGoogle provides but others don’t. So anyway, there are lots of these features and your gadgets get them for free. In most cases, they are just libraries which you could also get for free by using Scriptaculous or whatever…but still, with OpenSocial, it’s really, really, easy! No download or installation. (Although it must be said that with library CDNs like Google’s new effort, you can also use many Ajax libraries without installation too. The difference here is that at least some of these features are tied to server-side services as well.)

So, these days, OpenSocial may well be the easiest way for a newbie to learn Ajax, and for any developer to get an Ajax app up and running. I actually think we need more tools and services to allow standard Ajax apps – not gadgets – to get up and running fast too. After all, the UI in OpenSocial is based on a widget/gadget model, and this is a mini web app running on a bigger page. Nowadays, we have canvas gadgets, which are bigger, but still not so big and run inside another web page. What if you took the same cloudish platform principles and applied it to a big old Ajax app, occupying the entire page and with its own URL (though probably coming from the platform’s domain). You can sort of do that already by looking at the content of the gadget iframe, but it’s not designed for that purpose…and if it was, you could do some interesting stuff.

For instance, I envisage a simple-to-use cloud storage system based around principles of Persevere and CouchDB, and for limited use, it could even allow anonymous access. I’ll perhaps demo all this at some stage.

Hoorah for Aptana Cloud

Aptana Cloud has now been announced. This is exciting news and a step closer to server-side Javascript world domination. You don’t have to use Javascript, as the platform offers several engines, but from my perspective, the most exciting thing is the inclusion of Jaxer. So it should be easy to deploy server-side Javascript to a completely scaleable platform.

As for the more headline feature, it is a general cloud play. It will target the existing Amazon/Google/Joyent/others clouds (a “designed to go meta” as Dion puts it) rather than being a YAC (yet another cloud). My personal experience with the much-hyped Amazon EC2 has been nothing but pain, pain, pain. It might be fine for your run-of-the-mill Web 2.0 startup, but casual use? Forget it. Give me bog-standard ssh any day. If Aptana can solve that problem, and I have no idea if they can, but if they can, I’m sold. Key to the strategy will be integration with the Aptana IDE. That said, I find the Heroku idea of Cloudies (cloud IDEs) fascinating, so it would be nice if a product like this also offered some rudimentary cloud editing support in the future. (Enough to at least fix a critical bug from the comfort of an internet cafe.)

Kevin Hakman got in contact with me after the Javascript Grid article and kindly offered to let me review the beta, which is still on the cards, so I’ll let you know how it goes once I get access. I’ll also be interested to see how much more expensive it is to hit a Jaxer script versus a PHP script.

Today, Aptana unveiled its vision for Aptana Cloud, the next (but not last) aspect in Aptana’s strategy for providing an “End to End Ajax” suite of open-source based solutions for Web developers that use scripting languages. See Open for Deployment
  • The “engines” in Aptana Cloud are comprised of some of the most widely used and popular open source infrastructure: PHP, Apache, MySQL
  • Aptana Jaxer, the open source Ajax server based on the Mozilla browser engine, is also provided.
  • Ruby on Rails support is next in line. Complimentary to existing cloud suppliers
  • Architected to compliment leading Cloud providers like Amazon, Google, Joyent and others. Integrated right into your application life-cycle
  • The Aptana Cloud IDE plug-in will connect your Cloud instances right into your Aptana Studio/Eclipse application development, deployment and management life-cycles featuring:
    • On demand instant deployment to the Cloud
    • One click sync between your projects and the Cloud
    • Subversion source control
    • Remote DB Explorer and admin
    • Operational monitoring and notifications
    • System dashboards, logs and stats
    • Google Analytics integration
    • … and lots more as described at
    Early Access Program
  • Those interested in the early access program can request such at