For Flickr or such places like them it is a good idea to have very general services to cater to many front ends.

I think something that hasn’t really been said directly is that most of the applications that we build here at mediaRAIN aren’t general services. The services that we most commonly design, i.e., for AncestryPress, are not for general use at all, so optimization for specific use is the best idea.

So we need to understand the benefits of each solution and analyze our project to see if we need to go more general or more specific.

@Nate
You’re definitely right; however, backend developers can say the same thing about having the adapter on the front-end. They can remain blissfully ignorant of what goes on on the frontend. So there’s a pro and con for each of the possible adapter locations.

@Bryce
You know it! Seriously though, as a frontender I wouldn’t be completely opposed to doing the adapter work myself as long as it meant it was in the right location. It may just mean allocating more backend resources rather than more front-end resources.

@John
Good comments. Some of them require more of a response….

You mentioned that having the adapter on the frontend sometimes strips off an entire layer on the backend. The opposite is true as well. When the adapter is on the backend, it sometimes strips off an entire layer from the frontend.

I agree that if you have thousands of users using an application it can be nice to use their resources instead of your own; however, when you’re trying to cater to the user, using more of their machine might not be the best option. If it’s an internal application your employees are using and you’d like to distribute the process load to their computers it’s probably more reasonable as you’re not necessarily trying to cater to them. Also, keep in mind the user’s CPU may be just as taxed as the server’s CPU…the only difference is we might not be able to purchase more equipment to fix the problem.

You mentioned that an adapter on the client side is already sitting in context. Actually, only half of it is in context: the frontend half. Just as a backend developer creating the adapter has no certain understanding of frontend models, a frontend developer creating the adapter has no certain understanding of the backend models. The same goes for language constraints. If the backend class has a property name supported in the backend language, it may not be supported in the frontend language.

You mentioned a single API can serve multiple clients. This is true, but it doesn’t decrease the number of adapters needed. If two flex applications want to use the same API and they need a different class structure than what they receive, they’re each going to have their own adapters. If the adapters were on the backend, there would likely still be two adapters. You do bring up a great case though of when an adapter should not be on the backend and I should have addressed it. In the case of Flickr, they can’t provide a specific implementation for each one. It’s too expensive and time consuming. What better way to keep costs low than to push them onto the entity building the client application. Instead of building services specific to each need, they resort to a more generic, less optimized API interface. I say less optimized because such APIs ship a lot of extra data back that you may not need (the Bugzilla and iTunes APIs come to mind). They have to send it though because somebody may need it. Similarly, the API sends data in XML not because it’s the most optimized solution but because they have to provide a format that dozens of client technologies will support. If they had a gabajillion dollars to burn and were concerned with the performance of client applications, I’d be willing to bet they would provide an optimized solution for everyone who requested it. They don’t though because development and maintenance costs money and they don’t have a gabajillion dollars to burn. So, if our main goal were to provide an API that supports the widest array of frontend implementations and we couldn’t build a custom service for each, it would be a bad idea to have the adapter on the backend just as it would be a bad idea to use AMF. Why don’t we all ditch AMF and lean classes and replace them with XML that includes every data property? Because in some (most?) cases one entity either (1) is paying for development/maintenance of both the backend and frontend(s) (therefore no costs are cut by creating the adapter on the frontend) or (2) developers won’t/can’t be available to develop a customized service for each frontend client that needs one (whether due to money, resources, time or otherwise). If neither of those cases are true, optimizing the service by creating the adapter on the backend is probably worthwhile. If this weren’t the case, niche technologies like AMF wouldn’t even exist. All services would provide XML loaded with every possibly usable property.

I agree with your last point that a layer comes in handy when integrating with services from various vendors. I just want to clarify that when I said an adapter layer should generally go on the backend, I did not mean it was okay to exclude some form of a service layer from the frontend. It’s not. I can see how that may have been interpreted though because adapter logic can be placed in the service layer rather than a layer of its own. To explain how they relate in such a case, in most service layer implementations, there are interfaces (the object-oriented kind) that specify methods like getUser(), getOrders(), and getCustomers(). These are only the required method signatures, not the logic. The developer then creates service-specific classes that implement those methods. For compatibility with the AMF service, the developer would create a service class that implements the interface by providing logic for each of the required methods. The logic in this class would be specific to AMF and may or may not include adapter logic (mapping a backend class to a frontend class). Then the developer would create an XML service class that likewise implements the interface by providing logic for each of the required methods. The logic in this second service class would be specific to XML and may or may not include adapter logic. The existence of adapter logic in the XML service class is in no way dependent on whether the AMF service class has adapter logic within it. With the service layer in place and the application calls a specific service (if we’re talking about the client) or responds to a specific request (if we’re talking about the server), the service configuration just points to the right service class and all the methods are implemented as expected. So, when you say that any Flex framework should have some sort of service/adapter layer, they generally do have a service layer if they’re in any way related to Cairngorm, PureMVC, or just have a competent developer. The frontend service layer is slightly different than the one I laid out though because its calls are asynchronous and therefore must also deal with result and fault handlers. Other than creating classes to support a new vendor’s service (which may or may not include adapter logic), only small adjustments are needed to ensure flexibility with both. In other words, having the adapter logic on the frontend doesn’t make the application more flexible with new service types, you have to make new service classes either way.

On a related note, almost all frontend and backend applications should have a service layer if they support service-related communication. ASP.NET’s starter kit The Beer House is a fantastic example of a flexible data access layer implementation where you can swap different kinds of databases and it’s seamless. Although it’s for databases, the implementation for a backend service layer would be very similar.

Thanks for joining the conversation! Keep it coming.

(apologies in advance if your blog engine hates my HTML)

Seems like any significant database changes are probably going to require a recompile anyway. If you’re changing your data structure, it’s probably for a new feature or something that’s going to require a recompile anyway. If it really is insignificant, chances are you can wait to make it until the next release. For development this can be nice – I agree it’s easier to have it server side in that instance – but I don’t see this being a significant problem in a production setup.

The converse advantage of a small SWF and faster SWF is that when the adapter logic is front-side, the core server-side engine requires less weight as well. Sometimes it even strips off an entire layer. The advantage here is that when you’ve got thousands or tens of thousands using an application, sometimes a fat client is nice because you’re using user CPU time rather than an (already taxed) server CPU that you have to pay for. There may be situations where a server performance boost is more important than a client performance boost.

One other advantage to having client-side adapters in place is that the adaptation process makes more sense because it’s already sitting in context. When you’re typing or structuring data on the server side, classes (and their associated behaviors and attributes) have no meaning and can have confusing side effects due to server-side language constraints. When the adaption is happening client-side, those classes can be used better, and language-specific limitation (can’t have “delete” as a property name, etc.) make more contextual sense.
Generic data (adapted on the client-side for its own use) is more general purpose, and a single API method can serve multiple clients. If I expose a JSON or REST/XML API via the web, it’s easy for a wide array of client applications to consume. Large data houses realize this and it’s why you don’t see a Flickr AMF feed – it’s because *anyone* can use XML. There may be instances where other applications are using the same data, and building a parallel AMF layer doesn’t make sense once you’re already exposing that same data in a more general format (as far as typed data goes, at least).
Finally, I think any Flex framework should have some sort of services/adapter layer, just to make use of a wider array of services available on the web. Sure, an in-house built app can (and often should be) AMF typed server side, but a layer client side will come in handy when you’re integrating with SOAP/REST services from other vendors (Flickr, del.icio.us, etc.) or from a client doing their own services work in a non-AMF format. That way either side can adapt the data if it needs to.

The benefits that I see are that if I am a front-end developer, I don’t need to know the database schema! I don’t need to concern myself with why my classes are coming to me in a certain way due to associative classes, one-to-many relationships, inheritance, etc. I can remain blissfully ignorant of the backend, and view it as a black box without having any understanding of databases, or backend coding conventions from Java or PHP. Instead, I can simply focus on Flex or another front-end technology. Due to the increasing specialization in our industry I think this is a huge benefit.

Thanks for the insights!

It could be argued that if you’re not going to put the adapter on the back end then don’t bother doing an adapter at all–just deal with the raw data.

Really, the only valid reason for not creating an adapter and putting it on the back end is that the back-end developers might consider it to be a front end task to develop it, so the back end developers should not have to do it. If that’s their argument, then I think it’s reasonable to request help from the front-end developers in creating it.