amfast Python Remoting and Services Library for Flash, Flex and other AMF

pyamf is pretty sweet for Flash remoting with Pythonic server side, but now we have two nicely done and integrated remoting kits for python on the server side.

amfast is a new remoting library  that looks to be as sweet as pyamf (where sweet == fast and useful).  I am checking out amfast now but the speed boost alone might be worth it.  For instance, working with real-time games, when you need static content you need to grab that quickly sometimes via a content service.  The faster that link the better. It also has Twisted integration which is great for networking and SQLAlchemy integration which is in my opinion the best ORM for python (pyamf has twisted, django, pylons, sqlalchemy as well)

amfast is well documented and has some great examples.  If you have the Python addiction, check it.


  • AmFast is a Flash remoting framework for Python.
  • AmFast can use AMF to communicate between Python and Flash, Flex, and any other system that supports AMF.
  • AMF is a binary object serialization protocol used by Actionscript based applications.

Server Features

  • Support for NetConnection and RemoteObject RPC.
  • Support for Producer/Consumer ‘push’ messaging with HTTP polling, HTTP long-polling, and real-time HTTP streaming channels.
  • Support for authentication with NetConnection and RemoteObject.
  • Flexible Target mapping system to map message destinations to invokable Target objects.
  • Support for ChannelSets with multiple Channels to expose resources in different ways.
  • Built in Channels for CherryPy, Twisted Web, and plain WSGI.
  • Support for configurable Endpoints. Use AmFast’s built-in AMF encoder/decoder C-extension, or use an external AMF encoder/decoder, such as PyAmf for a pure-Python implementation.

AMF Encoder/Decoder Features

  • AMF0/AMF3 encoder/decoder written in C as a Python extension for speed.
  • More than 10x faster than the PyAmf encoder/decoder (even when using PyAmf’s optional C-extension).
  • Map custom classes with ClassDef objects for complete control over serialization/de-serialization.
  • Full support for IExternalizable objects.
  • Data persistence with SqlAlchemy including remotely-loadable lazy-loaded attributes.
  • Actionscript code generation from ClassDef objects.

Tags: , , , , , , , , ,

  • BogImp

    I can run this under Google App Engine?

  • drawk

    BogImp, haven’t tried. I know pyAMF works on Google AppEngine but I am sure it will be ported soon.

  • Nick Joyce

    I am one of the developers of PyAMF.

    The AmFast de/encoders are written in C, whilst Google AppEngine disables C extensions (for obvious reasons). Theoretically you could run AmFast on GAE but PyAMF would be required to do the heavy lifting (as it has a pure python option). It would be a thin wrapper at best.

    PyAMF 0.4 series concentrated on stability and integration (we have good support for BigTable, Django etc.), not speed (premature optimisation being a factor).

    The current development (which will become PyAMF 0.5) is focussing on speed. The current trunk is only around x2 slower than AmFast with the C extension enabled for encoding, whilst the pure python version is around x5 slower. This is a work in progress and we reckon we can get similar timings to AmFast without losing the flexibility/stability of the library.

  • ryan


    Thanks for your work on PyAMF it is great! It is also excellent that there is a focus on speed in .5 with another library out there. Maybe both libraries can help one another with innovation and speed. And best of all start hooking up the flash world with python backends, which is the way to go for happiness :)

  • Vlaserted

    Как хорошо что удалось отыскать такой замечательный блог, и тем более отлично, что есть такие автора толковые!

  • Marinkina

    Кстати, если закончаться фото Одри, то можешь в фотошопе старые фото накладывать на новый фон, так и разнообразие будет и ты работать продолжишь

  • ziggy

    would consider pyAmf if it had support for authentication for RemoteObject

  • limscoder


    I’m the main developer of AmFast. Thanks for the write up.

    The goal of AmFast is to create a flexible and customizable AMF and Flex messaging framework, where the encoder/decoder and transport layers are loosely coupled with the core messaging logic, so that it is easy to swap out individual components. For example, AmFast comes with a built-in C-extension for encoding/decoding AMF, but if you can’t compile the C extension, you only need a couple of extra lines of code to use the pure-Python version of PyAmf as the encoder/decoder instead.

    The PyAmf/AmFast combo is more than a simple wrapper. If you’re already using PyAmf, you can continue to use PyAmf for encoding/decoding, but use AmFast’s remoting/messaging core to implement the Flex messaging features that aren’t supported by PyAmf yet (Producer/Consumer messaging, RemoteObject authentication, sessions, exposing AMF packet and Flex message objects).

    I’m hoping that we can find some common ground to integrate features and code once the PyAmf project starts working on implementing Flex messaging.

    In regards to the GAE question, AmFast can use the pure-Python version of PyAmf as the encoder/decoder to avoid compiling the C extension. However, AmFast’s Flex messaging implementation needs to store session information about each Flex client. Currently AmFast stores that data in memory, so Flex messaging (Producer/Consumer, RemoteObject authentication) won’t work with GAE, because memory is cleared after every request. Simple RPC calls will probably work just fine with GAE, but I haven’t tried it yet.

    The next planned version of AmFast (0.4) will feature multiple back-end options for in-memory or persistent storage of connection session data (probably implemented with the Beaker package), and I hopefully will have time to cook-up a GAE example with Producer/Consumer messaging.

  • drawk

    limscoder, sweet it is a great toolkit so far and some great things planned for it! I am happy to see more python toolkits as I believe it has a huge future and hoping Google completes Unladen Swallow. At that point you won’t have to worry about the C-extension as the LLVM Python build will be as fast as C frequently. Until then this is awesome to have fast remoting with a C extension.