Back when I joined Flumotion, my team was given the choice between implementing a HTML/JavaScript or a Flex powered back office. Most developers I know would immediately turn down the later for a number of reasons:
- Platform portability, notably turning down mobile users.
- Flash plugin sometimes appears to only work properly on Windows machines, raising performance issues.
- Commitment to a proprietary technology.
- Smaller choice of developers and community resources.
- What is it with Adobe and their beloved RIA buzzword anyway? I don’t see anyone else using it!
- Obviously not as trendy as Ajax.
among others that spiced up the discussion.
But there were some particular reasons to strongly consider it in our specific case. For one, we would be working with media management, editing and playback of video, a technology closely tied with Flash at the moment, so it was really about going with Ajax with some Flex components or just Flex alone. Truth is I already had my share of pain working on projects with a heavy Ajax interface, from what our Product Manager expectations of the product, I could see those memories coming to light again. Furthermore, and more on a personal perspective, I felt tempted to give it a try and only afterward draw my conclusions. Based on that, I handed my vote out to Flex.
A few months later, I have a better shaped opinion, I had some nice surprises, as well as really disappointing ones!
I need to give credit to PyAMF for the achievement of making Python and Django integration the easiest possible. On very few occasions I had to step out of my backend bubble and worry about issues regarding frontend. The AMF protocol itself helped here, a little but nice example feature I recall is that datetimes are always passed in UTC, being the Flash plug-in responsible of handling the offset, based on the client timezone system setting. Not having to worry about details such as these was a joy and made the development process faster, allowing me to focus on backend performance. In the end I was developing a Python request handler, very far from your regular Django application, using little more than the ORM and URL handlers.
But there was a few downturns along the way. First, only the fact that code was compiled made me feel in a strange place a lot of times. Every small fix implies a full build and update on production code. I believe that hot fixing should be avoided at all cost, but it is still needed sometimes and this only made it harder, heavier and even more dangerous. Then of course there were the problems of the Flash plugin on Linux, it is really frustrating for a guy that stays 80% of his time on a console having to deal with Firefox taking away all system resources the minute you open something Flash making it virtually impossible to test without booting up a virtual machine. On AMF itself, I never quite understand for the data transferred to come “encrypted” in a weird format, it certainly didn’t made it feel safer or smaller. Also, the fact that each messaged carried a message ID and time, made it harder to smart cache responses. Although I came up with a interesting cache decorator for AMF requests that I will post in the future, I would have preferred to do it on a lower level so that I wouldn’t have to waste time decoding the AMF requests (yes, as fast as it is it’s always unneeded overhead).
But the one thing that really annoyed me was the cross domain sandbox issue. As the project architect, it was very frustrating being forced to spread several copies of a crossdomain.xml file that makes very little sense to me. To date, no one as yet succeeded in properly justifying it and proving me wrong, but I will get into this issue on a following post, don’t worry.
As a conclusion, in the context of this specific project, I believe we made the right choice. Still, I very much doubt that we will see Adobe’s “Rich Internet Applications” taking over Ajax anytime soon. The new media support on HTML5 is here to confirm that. Rare examples like Google Wave make me believe that given the right developers (I presume), it is possible to make very nice JavaScript powered applications.
That said, on a future decision, my vote would again depend on the project details and target audience, but in most cases I can think of at the moment I would have to go with Ajax.
If you have a similar experience with a different outcome, I would very much like to hear you!
…On AMF itself, I never quite understand for the data transferred to come “encrypted” in a weird format, it certainly didn’t made it feel safer or smaller….
Well AMF really reduces the size of a message notably, may be you should update that
http://www.jamesward.com/census/
James Ward did create this test, seems not be working right know but was a very interesting comparison tool
Great post anyway
Well, as with any other generic compression algorithm, depending on the data size, you always have profit at some point.
That said, maybe on bigger requests/responses AMF takes the prize in making the transfer smaller. I noticed that James did is benchmark transferring 5000 objects, knowing that alone, seems like a huge amount of data to be transferred to clients. When dealing with a high number of of concurrent users, translating on a really high of concurrent AMF requests, I would keep the services as simple as possible, delivering the least possible amount of data. This is where I believe the compression doesn’t help much, it will very likely actually make it bigger, processing longer and, as I wrote above, harder (or impossible) to reply from cache previous to decoding.
But then again this all depends on the application we are talking about. I believe that if your application actually needs to transfer that huge amount of data to every single client, then maybe you have other priorities then communication performance. Only taking a wild guess here anyway.
( right now )
Actually yes, as usually happens, it all depends on the kind of problem you’re dealing with. As specification of AMF3 says:
“Action Message Format (AMF) is a compact binary format that is used to serialize
ActionScript object graphs.” (http://opensource.adobe.com/wiki/download/attachments/1114283/amf3_spec_05_05_08.pdf)
So they’re thinking in the generic case, as they intend to provide a transfer format between server-side applications and client-side ActionScript applications, putting focus in easy-of-use (and maybe perfomance) in receiving objects in the ActionScript side.
For similar purposes, but with double-blind approach (i mean, any language in both sides), plain formats like JSON and XML are better, since they can be generated an readed without any extra layer to deal with and without data compression/uncompression needed.
So AMF only makes seems to exchange data with ActionScript applications, and is in that context where get the best of itself. No sense to use it in other enviroments.
Interesting point of view ( both )
@ycneo …client-side ActionScript applications… not really true, AMF3 specification has been opened and it’s applications are traspassing the Actionscript frontier ( see http://github.com/nesium/cocoa-amf, is an example of using AMF in a non Actionscript environment
)
On the other hand @ricardo as you may know I’m not a really backend guy, but …When dealing with a high number of of concurrent users, translating on a really high of concurrent AMF requests… Well one of the main advantages of using AMF is the fact that you are recieving actually objects ( this occurs on Java Backends and I think it’s coming on python ), which implies no deserialization on the client side. In addition to this, if we have a Backend which is able to cache the requests, this number of translation should decrease significally
I found this while answering the comments http://www.5etdemi.com/blog/archives/2006/12/clearing-the-fud-on-amfphps-speed-versus-json-and-xml/
is a 2006 post, but I think it’s still good information
A little late, but anyway…
On advantages of AMF serialization over other BINARY serializations:
1) integer are compressed (small positive ints can use just one byte). At large, this alone offsets the header stuff.
2) object references, if an object appears more than one time in a graph, then it must be described only once, then it’s referenced. (Strings too!)
On advantages of AMF serialization (and most other “binary” serializations) over “descriptive” serializations:
1) The client can be instructed to deserialize properties without giving them a name. This is possible only when both sides agree on a specific way order to serialize things. In flash there is sort-of alphabetic order.
2) There is space for metadata, allowing for typed arrays, subclass deserialization etc (XML has too, but then you need another piece of data, an XSD, and then synchronize both parts’ classes to the XSD)