Going All-the-Way with the Client-Server App Concept
So you're going to build a big web app. A long-lived, single-page app with lots of data and Ajax updates. Maybe something like Gmail.
the traditional server-side web framework
Many server-side web frameworks were primarily designed to build traditional web sites. A request for a page arrives to the server. The server gets the necessary data from the database, assembles the HTML presentation of that data and sends back that page. The response page may even have a form or two. That is great if you want to build a traditional web site. It is the only way, in fact. The server has to do all the work.
The traditional server-side web framework must combine data (e.g. in files or databases), presentation (e.g. HTML), and application (e.g. links and forms) in pages. This combination tightly couples the work of the server-side and client-side programmers. This can be a development problem for a big single-page application as the server-side and client-side programmers are working on the same files but primarily concerned with different aspects of the program.
The client-side programmer is worried about the wow-factor and marketability of the user interface presentation. Also the client-side programmer is interested in the API that the server provides for Ajax interactions. Security is a much smaller concern for the client-side programmer as there isn't too much he can do in that department anyway.
GET /todos/2009/04/21 and get the EJS version or you can ask for pure data
If the large amount of coupling that a traditional server-side framework might lead a programmer to add between the server and client programs could be reduced, both sides would benefit and development time would be reduced.
the non-web client-server app
There is a model for client-server applications that is older than the web. In this model, the client has applications installed first. These applications are concerned with the user-interface and getting and sending data to a server. The user interface application doesn't have the data. The server knows about and stores data. The server doesn't know anything about the user interface. The two sides talk only through the server's data API. It is a very small and can be a very clean interface between two large parts. Such a data API is easy to document, understand and test. If the client-side presentation changes the server doesn't need to change at all. If the server code is updated for speed improvements, bug fixes, etc, the client-side doesn't necessarily need to change.
A key part of this architecture is the client has the application installed before it requests the data. They don't arrive together like they do in many web pages. The answer for cleaner web application implementation is separating the application and the data.
going all the way on the web
Taken to the extreme the static page can be as short as the following.
When the application page loads, the client asks for necessary data though the server's generic data API (e.g. JSON, XML, CSV response formats.) Assuming valid auth information is supplied in the request header, the server returns the data. The client application uses this data to build the user interface. As the user continues to interact with the user interface, the client application can continue to communicate with the server though the server's data API.
What I like so much about this system is the server-side programmer is only concerned with creating a secure data API. Removing the complexity of the client-side application means less code in the server-side programmer's repository. It means tests are easier to write as they are only testing data structures that don't change when the presentation changes.
What I like so much about this system is all the client-side application files can live outside the server-side application's code base. Even in a different repository. There is no connection between the two except for data requests. A mock server can be built to return dummy data specifically designed to help user interface development. The entire client-side app is in the hands of the client-side programmers.
What I like so much about this system is the server and client apps can have different release cycles with less time spent coordinating between server and client programmers.
an extra request
If the application and data are mixed, as they are in many web sites, then they arrive in the same first request.
Separating the client-side application from the data might mean an extra request. The client first requests the application. That application then requests the data. This cost is likely small and may already be in place in many web pages that don't quite go all the way.
securing access to the client-side application page
there is no silver bullet
I'm not suggesting every page on every site would be well architected if designed to work as described in this article.
One of my long-term work projects over the past couple years has been a long-lived, single-page web application. The way we built it is quite close to what I've described above. The application page is very small. Most of the application's data is retrieved through the server's generic data API. Unfortunately we didn't go all the way. The page does contain a small amount of user specific data and it is still dynamically generated. Many times I do wish we had gone all the way. I know complete client-server separation would have made development faster and easier for both sides. I'm looking forward to going all the way some time in the future.
Have something to write? Comment on this article.