Flash remoting for PHP: A responsive Client-Server Architecture for the Web

The need for Remoting

Let’s say you want to exchange data between Flash and a server. A common method is to use XML. Actionscript has a built-in XML parser, so you can load XML files directly from the server and read the data that’s inside. But what if you wanted to get data from a database? What developers used to do is create, for example, a PHP page, connect to a database, make a query, loop through it’s elements, create a long XML string out of the data, and send it back to Flash. Back in Flash, the inverse process would be done: get back Flash-readable data from an XML file by working to the DOM.

What’s wrong with this process? Well it is a tremendous waste of time; a lot of resources are wasted figuring out what schema to use, implementing code on server and client, and debugging. All of this for the purpose of constructing something on the server that you immediately destruct on the client side.

Enter Flash Remoting

Flash remoting is a toolkit including a server gateway, components, actionscript classes and a debugger. On the Flash side, you have a bunch of actionscript classes that handle decoding and encoding data. You have a gateway on the server side that also encodes and decodes messages and acts as a dispatcher to call the required service. Data is exchanged in the AMF format, which is a binary format inspired by SOAP. The gateway and the actionscript classes translate data into this neutral format, and this allows language specific data to be exchanged transparently. The bottom line: exchanging data between Flash and the server is fast and simple.

Why Remoting rocks

Remoting makes the transfer of complex data types, like objects, arrays, and even resources dead simple. This allows you, for example, to transfer SQL resultsets elegantly: just pass a resource link to the gateway, and Flash will receive it as an instance of the RecordSet class. A typical example of this would be:

return mysql_query("SELECT * FROM db");

On the Flash side of things, the Datagrid component can directly use the RecordSet as a dataProvider, like so:

function remoteFunctionReturn(re:ResultEvent)
{
    _root.myDataGrid.dataProvider = re.result;
}

As you can see, transferring complex data is dead simple.

A common problem with XML data exchange is that it’s difficult to see what’s actually being sent and received from and to the server: it’s very difficult to debug because you’re basically blind. Flash Remoting comes with a NetConnection Debugger which allows you to easily see exactly what is being exchanged, making it a lot easier to debug.

Flash Remoting is also made to work seamlessly with the v2 components. When you receive a recordset object in Flash, you can directly use it as a data provider for your components, so you save another processing step there.

Finally, even with the advent of MX 2004 data components that make XML and SOAP handling easier, Remoting still has its place. AMF requires up to 75% less network traffic when compared with SOAP, because AMF is a binary format. The difference is especially clear when complex data types like resultsets are sent. Since the format is native to the Flash player, parsing and encoding are also much faster than with the Web Services connector. A performance benchmark is available here.

Consuming a web service from a remote domain is normally prohibited by the Flash player’s cross-domain policy, so you will need to write a proxy in a server-side language. You’re better off using Remoting’s web service functionality, which gives you a free proxy, a free debugger, and much more efficient data transfer between client and server.

The only thing that Remoting didn’t have going for it initially is price. Now, with AMFPHP, you have a solid implementation of Flash Remoting for PHP that is free and open-source.

Further advantages of Remoting

If your data structure is simple, Remoting may not help much. Say you request a list of products and they all return ordernum, descr, price and image_url. The code to pick up that data is fairly simple using either LoadVars or XML.

You cannot just pass a “string” from Flash to PHP, or PHP to Flash… you have to send a URL encoded string. So you have to add a little code on both ends to handle that. What if you need to send arrays? Objects? DataSets? You have to write serialization/deserialization for complex, non-primitive types to send over the wire via URL encoded strings. But why would you want to write your own classes when Remoting already does all this stuff very well?

The Flash Player has built in support for Remoting; parsing of AMF is done natively using C++ code, not ActionScript. Using the v2 components to consume Remoting RecordSets directly, means populating a datagrid from a database takes about 3 lines of AS. You gain the performance and scalability benefits of the binary AMF packet format with very little code on your part. Sending strings across the wire is just not as efficient. When your application is being utilized by a lot of users this can be a big difference. Flash is presentation logic, and should stick to doing what it does best making things look and work good for the end user to be able to complete their task. The heavy lifting of data and business logic should be passed to someone more capable like PHP through AMFPHP, Java through OpenAMF or ColdFusion using the built-in Remoting. Creating coding frameworks is a waste of your time; the whole point of Remoting was so various tiers could easily talk to each other in the normal fashion most programmers are used to; function calls and events. With LoadVars parsing, you are blurring the lines between back-end business logic tier, and front end presentation logic tier which is bad design. Besides:

It’s faster than XML or LoadVars
You don’t have to think hard to find a scheme for your data like XML or LoadVars
It scales much better than any other solution
The actionscript 2.0 classes provided by Macromedia are well thought out, use an event model that’ll fit any coding style
The RecordSet object includes stuff like filtering and ordering out of the box, saving a lot of coding
Handling complex data types like arrays and result sets is so much easier than any other solution
You get the NetConnection debugger, which makes debugging a whole lot easier
You get free authentication
You can easily consume web services (free proxy plus free serializer)
You get service descriptions from a windowSwf in the IDE
It’s meant to work with FlashCom out of the box
Standard classes means you can share code between projects and read tutorials and actually understand them

AMFPHP compared to other implementations of Remoting

Most implementations of Flash Remoting (with the notable exception of FlashORB) use Remoting-specific objects and structures on the server side. For example, MM’s .NET implementation uses ASObject to wrap actionscript objects, and ColdFusion has a Flash struct to handle things like pagesize.

AMFPHP, on the other hand, was created with interoperability in mind, and hence does not use Flash-specific objects or keywords. The classes created for the AMFPHP framework are standard looking PHP classes with a methodTable attribute that won’t interfere if you plan to use these classes for other purposes. Actionscript variables are transferred very naturally as outlined in handling datatypes.

AMFPHP is a real, interoptable Remoting gateway, unlike language-specific solutions like PHPObject. That means that it’s easy to migrate applications that were made for ColdFusion, Java or .NET remoting to the AMFPHP framework: the Actionscript is basically unchanged.

Finally, a distinguishing feature of AMFPHP is the complementary service browser, which allows you to view your service specs using a web browser. The system even generates Actionscript for you, making it much easier to get started if you are a Remoting beginner.

Why AMFPHP rocks

It’s free
It’s fast
It’s open-source
The framework is pattern-based and the programming is real pretty, meaning it’s not overly difficult to extend
You work entirely in OOP, resulting in a much cleaner coding style that’s easier to maintain.
Gateway and services are separated, meaning classes are reusable outside of AMFPHP
AMFPHP is very flexible and only requires one AMFPHP specific variable to be defined per class, methodTable, again meaning it’s easy to use your classes outside of AMFPHP
It generates code for you through the HTML based service browser, meaning you save yourself a lot of typing (that’s good for your wrists and fingers)
The SQL handlers are very complete, meaning you can use mysql, postgress, adodb, sqlite, mysqli, and a few others, and it’s incredibly easy to make new sql filters
You get as verbose errors as you could possibly get with PHP
You get paged recordsets
Did I mention it scales much better than any other solution you can work with?
AMFPHP doesn’t try to reinvent the wheel, unlike others (like PHPObject), meaning it’s inter operable with ColdFusion, ASP.NET, java, python, Perl, whatever Remoting you can think of
We have lots of good quality docs for it
A lot of people with large sites are already using it (see showcase), so it’s not like some bs project that nobody’s ever heard of.
There are already a lot of resources on AMFPHP (like sephiroth.it and flash-db.com), and it’s certainly a lot more community based than some other implementations of Remoting, meaning you’re not alone