Last week we released gTrax as a partner in its Google Marketplace launch. We have big plans for the application, so we wanted to make sure we had an extremely robust architecture underneath.

There are three key pieces of technology that underlie gTrax. We make extensive use of the Model-View-Presenter pattern, Command Pattern and a Global Event Bus.

Model View Presenter

gTrax is built on GWT (Google Web Toolkit). This allows us to write an extremely fast complex application using industry best practices. It has long been accepted in development that it is a good idea to separate application logic from the actual display of the app.

The method we use to separate the components is known as Model-View-Presenter. The idea is that there is an in-between layer known as the “presenter” which handles things like updating Objects and data while only notifying the user interface when an update is needed.

A prior programming paradigm was known as “Model-View-Controller”. While this idea works well when working with applications that treat each new screen as a completely new environment it can quickly bog down a web-browser application and force complex logic into views.

Command-Pattern

The command pattern is a way of associating client-side Actions with server-side Results.

Imaging that you have a “Create User” action. You know that what you want back at the end of the request is an object representing the new User. Using the command-pattern, you would create an action which embeds in it the details that you might know about — First Name, Last Name, Email address for example. The action is then passed through an Action Handler — in most cases a server-side script which can then process the action and save it to a database. The server-side handler would then fill in the remaining data which the client had no previous knowledge of, such as Database keys, timestamps, etc.

In fact, using this pattern you aren’t even limited to requiring the client be online and have access to the server! It would be just as easy to write an action handler which saves the action (via HTML5 data storage, or Google Gears) and processes the request when the application server is again available.

Global Event Bus

Larger applications often use “Events” to allow other parts of the app to hook into common actions. For example, you might have a “Close Tab” event when the user closes a tab in their browser. Other parts of the project could then ask to be notified when the event is created.

A global event bus allows you to not worry about when and where the event was created. Instead you have a global hook where anyone can listen in!

An analogy would be like sending out an email to a group of people. You might have mailing list software that supports lists of contacts. Sending an email out to the “project members” list means that other members in the organization might miss out on information that they are interested in. If instead you were to blast out an email to the entire organization everyone would be notified. The analogy falls short in that with emails you might be frustrated with all the messages you are getting — in a web application there is no overhead to having this type of global messaging system.

Conclusion

We make life easier on ourselves in several other ways too! Google Gin and Google Guice are two other examples of ways that we can decouple interface from logic.

When designing a web application it is vitally important to build up from a strong base. Ensure that you spend MOST of your time developing a framework that will allow you to implement whatever features you need or want in the future.