476 Part II: Developing an Ajax Library^
Coupled or Decoupled Architecture
Now that we have seen a complete example, we see that the interplay between the client
and the server can get a bit involved. Depending on a person’s background or philosophical
bend, there are two general approaches for attacking the architecture of a more complex
full-Ajax style Web application:- A more client-focused approach with relatively loose coupling
- A more server-focused approach that tends to be more tightly coupled
What we mean here in terms of coupling is how interdependent or connected the client
and server side of the application are to each other.Loose Coupling
Throughout most of the book, we have followed a loosely coupled model. We developed
various JavaScript widgets and even full applications but really didn’t spend an inordinate
amount of time discussing the server side. We presented URLs as servicing endpoints that
our client-side scripts would make calls to expecting to receive data back or have some
function performed with an acknowledgement of success or failure. As long as the URLs
presented a consistent interface, we really didn’t care what the back end that drove them
was built in—it could be written in PHP, Java, C#, Ruby, or any language under the sun.
This implies we could swap out the back end as we like, and conversely, the back end
wouldn’t have to know much about the front end calling it as long as it did so correctly...
or did it?
The separation of duties between client and server in the loosely coupled examples we
built wasn’t always so clean and separate in an absolute sense of things. We did not always
employ a full MVC (Model View Controller) pattern, and maybe we shouldn’t have. Patterns
can be over applied, making things harder rather than easier. In fact, very often we saw it
was simpler to render portions of the output (or view) in terms of HTML fragments on the
server and ship them to the browser for direction consumption. In this chapter, we showed
that you do not have to take that route; you can and should seriously consider sending
presentational templates to populate with data to the client side when the requestor is
capable of doing so.
The purity of the solution isn’t really the point. It is simply to remind readers that there
is interplay between client and server here. We are loosely coupled, not decoupled. The
client needs to signal the server with what it can do and what state it is in, and the server
still needs to understand the client capabilities and respond appropriately. The server-side
program has to know what template to return or what to render like, and the client might
also need to know what kinds of things to send in order to receive the appropriate
presentational components.Tight Coupling
Even if the goal of pure separation were clean and achievable, there are downsides to the
approach. We have in our architecture a significant problem that some term an impedance
mismatch, but we call too many moving parts. We have markup; style sheets; media objects;