Flex is MORE than just a pretty front-end
Author: Thomas Gonzalez
One of the most powerful aspects of using Flex is not necessarily the language or IDE itself, but the design patterns that the combination of Flex and the Flash Player allow you as an software architect to implement. For developers who are used to building large scale web applications, the traditional approach is to use some version of an n-tier architecture where your platform consists of a data persistence layer (fault tolerant DB's), web application layer such as .Net, Java, ColdFusion, etc (to maintain session state for stateless HTTP and enforce business logic), and your presentation layer (HTML, Javascript, Flash, etc..)
This is a topic that I have been thinking about quite a bit over the last couple of years since I started using flex, and the more I work with Flex the more I stand behind the conviction that packages like Flex/Flash offer us a new paradigm for web application development. I realize this is a long post, but my hope is that others out there in reading this post will start to think about web application development in a new light and realize there is potentially a more powerful (and enjoyable) way to design web applications.
The traditional n-tier approach, while tried and true (and an architecture that I have implemented in more solutions than I care to remember) has several shortcomings that are primarily related to the limitations of web technologies at the time the n-tier approach came into vogue almost 10 years ago. Below I list four fundamental shortcomings with this approach, although I am sure there are several more.
Shortcoming 1 - Multiple Languages/Environments:
Taking this layered approach to building applications, requires the developer to code in several languages across several tiers and IDE's. Even in the most simplistic web application, the developer is going to have to be writing and debugging some type of SQL via one IDE, then working on some application tier code with something like Java or .NET, and finally writing their presentation layer with some HTML/Javascript or Ajax Library. All said, the developer is going to have to be pretty efficient at knowing at least 3-4 completely different languages as well as their associated tooling, or even worse, have to distribute that work across multiple team members. Then, when it comes time to debug the application, even in the most integrated of environments, the developer will be debugging through several different debuggers, trying to track data structures and logic as they pass through each layer, all of which takes time and not a particularly efficient way to troubleshoot an application.
Shortcoming 2 - Brittleness:
I don't care how "loosely" coupled or abstracted you have designed each layer, by its nature this approach tends to create brittle designs where each layer is written in its own language and has unique implementation details. In my experience, no amount of planning for future functionality and abstraction fully covers you in your design, and more times than not, an innocuous feature request like "Gee, it would be nice if we can capture the users surname on our registration form" has the developer modifying the presentation layer, business/app layer, and data layer to accommodate a relatively simple request that ends up rippling through every layer of abstraction in unavoidable ways.
Shortcoming 3 - Maintaining Client State on the Server:
HTTP by its very nature is a stateless protocol, each time that browser loads a new page, all state is lost (cookies aside), sorry folks, but that is the way it was designed. For that reason, web application architects find themselves jumping through all sorts of hoops to maintain state on behalf of the client within their centralized web servers. This problem becomes further exacerbated when we are designing a scalable web application with many web application servers. You now have to deal with load balancing IP requests across multiple web servers and dynamic client IP pools. This makes the architecture required to build out a web farm a much more complex issue for your application design, testing, scaling and debugging.
Shortcoming 4 - Browser/Desktop Compatibility:
This is so obvious I don't need to hammer it further, but needless to say writing web applications (or even desktop ones) that behave nicely on a wide variety of clients and environments requires writing LOTS of code that deal with compatibility issues and adds zero additional functional value to your application.
So how does a technology like Flex address these issues? To me, it wasn't immediately apparent, as I when I started using Flex I just thought of it as an easier way to build a more attractive and interactive presentation layer, but the more I used it and the more I saw how powerful the Flash Player, was I started to realize that there was a real opportunity to do things differently. It was at about this time (a couple of years ago) that I was starting the initial architecture for our on-demand BI dashboard offering, which was the flagship product of the startup I had co-founded.
When evaluating architectures and design patterns I wanted an approach that was going to maximize developer productivity while giving us a consistent and maintainable code base. I looked at frameworks like Cairngorm (which largely borrow from established Java design patterns) and ultimately with the help of my VP of Engineering ended up designing a custom framework and architecture over the course of about 6 weeks. This framework allowed us to successfully go from a written spec to commercial product with two live Fortune 500 clients in just under 6 months with a team of three developers including myself who was only working on the product part time. All in all, I was very proud of our effort and what we were able to accomplish in such a short amount of time, and outside of having a very dedicated team who worked extremely hard, I attribute that success to being able to leverage a completely new paradigm for web application development.
So what did we do that was all that different, what was our secret? Well, obviously Flex was a big part of it, but more so it was what Flex allowed us to do from an architectural perspecitve. Fundamentally we still had all the basic pieces of an n-tier architecture in place with a DB on the back end, a web service bridging the client to the DB, and our client code within Flex. But what was different was WHERE we put the code for those layers. When you looked at the composition of our code which was spread across SQL in the form of creation scripts and stored procs, .NET for our C# web service and Flex for our client, 98% of our code was all written in Flex. We had less than 3000 lines of code within SQL, less than 1000 lines of code in .NET and the rest was all Flex!
How did we do this? Why did we do this? Well, we essentially condensed all of our abstractions layers into one platform and language - Flex/ActionScript. We still had a "presentation, business, data" layer but it all existed within our Flex classes via a MVC framework approach. Our model classes would serialize themselves into XML which would then call our web service which primarily served as a secure pass through to our DB, and then the DB would digest the XML via associated stored procedures and update or retrieve data in the appropriate tables. This meant when we had changes to the spec and had to add that a new data field we simply updated our Flex UI and underlying model class and the appropriate stored proc on the DB. The separation of layers worked beautifully, all the UI code and underlying model code was in one environment and IDE, while all the code to maintain referential integrity of the persistence layer sat in the DB where it belonged. The primary motivation for me to adopt this approach was to focus as much of our development energy on directly enhancing functionality versus working on plumbing and repetitive coding tasks that did not directly add to the feature set.
This approach afforded us huge advantages in our development. The single biggest advantage was the speed of development, once our data tier and pass through web service were stabilized (with less than 4k lines of code total, that did not take too long) we could debug all of our code in one environment. The whole architecture of the platform sat in one place, Flex, and while our .Net web service exposed some utility functions for us (like SMTP access, and some server side file manipulation) we rarely had to leave the Flex debugger for troubleshooting. The second big advantage that we had was how we could scale our application on the web tier. Since all of our complex client state existed within Flash (and thus on the client) the only load our web servers received was for the stateless pass through requests to/from the DB and for some utility work. Thus, we did not have to maintain any session state on our servers and scaling out the web farm was simply a matter of adding more web servers behind a load balancer. The back end DB still required clustering for fault tolerance and scalability, but we had a relatively simple DB schema that made this easy enough to achieve.
All in all, had we taken a more traditional approach to designing our application I can confidently say it would have taken us at least 50% longer to build with half of the interactivity and robustness that our application released with on version 1.
This approach worked for one primary reason, and that is the ubiquity and the power of the Flash Player in combination with the abstraction of ActionScript 3. Yes, everyone knows that Flash has something like a 98% penetration rate, and that a .swf file is going to act pretty much the same regardless of the browser or OS it plays within. But, when Adobe released Flash Player 9, it left the leagues of a neat way to show cool animated effects, and offered a true platform to deploy robust applications against. The performance of the Flash Virtual machine is pretty amazing when you consider how compact it is. For instance I can manually filter row by row through thousands of database records using powerful regular expression match patterns within mili-seconds ON the client. Flash is not without its warts, but all-in-all a very compact, and powerful platform to write code to. I encourage other web application architects to look closely at the Flex/Flash combination for their next project and consider how they might benefit from this approach.
Nice article. Curious, did you have any security concerns at all with now having all your complex logic residing in the client app (basically a swf that could be potentially decompiled) ?
Anonymous,
That is a good point, and one that we considered. We did end up deploying a "little" back end logic that supported our role based security system, so each HTTP request back to our application server carried a user id and password and would be authenticated for permissions. Our database also created audit logs for each request so we could track and monitor malicious requests if we desired. Additionally, our web service, in its function as a pass through service also performed checks on the SQL strings to mitigate SQL injection attacks.
- Tom
There are still reasons to have a tiered server layer, esp. if there are complicated/conditional steps that need to be done, and you don't want the client to be wasting it's time with N remote calls, when one would suffice.
Falken,
I agree with you, in certain cases it still makes sense to tier out your app in a more traditional approach.
But, I am curious, what type of "complicated/conditional" steps would you need to execute on the server that would require N steps? Are you talking about conditional logic that has the application going back to a DB on each step of its logic?
- Tom