Now that we've started applying the things we've learned to a real-world application, we're going to gradually ramp up the complexity of the projects we build. By designing and creating a code base that imitates something an actual customer might pay money for, we're not coding abstract examples that exist in isolation. We're building something that showcases some of the design decisions you will likely face as a software architect.
In this chapter, we'll build a monitoring dashboard that can be used to view metrics from an application server. Developers and system administrators will use applications like this to visualize the performance of their servers and monitor load at any given time.
Such an application could be used for internal monitoring, or it could be deployed as a Software as a Service (SaaS) that could be resold to other users. Either way, it will serve as a great demonstration of the power of view models; we'll be expanding what we already know and will be using it in a more advanced way to shape the data we receive from the server. In this chapter, we'll cover:
- Designing the user interface
- Designing our data layer from the
Ext.data.Modelthrough to the view models needed to support our UI - Using multiple view controllers
- Building components that are reused across views
- Adding routing to allow users to bookmark each screen of the application
- Using view model filters to focus our view of the underlying data
By the end of the chapter, we'll have fleshed out the concepts we've already begun to cover and introduced some new features (such as routing). These are important when designing the user experience for an application.
We're going to approach this as if we're designing an internal program, one that monitors another application in our theoretical software development shop. Although this means we're not bound by external customer requirements, it's still important that we follow all of the design guidelines we've already learned. This maybe an internal application, but it's still got to be robust, meet the expectations of stakeholders, and be maintained in the future.
This application will have several screens to view the various properties of the app being monitored. We'll have a dashboard screen that shows an overview of the important metrics being monitored. Then, for each of these metrics, we'll have individual screens that allow the user to drill down and filter the data. As each of these screens will be variations on a common theme, we'll only build-out a couple to demonstrate the concepts, but the framework we'll build with this application means it would be trivial to add more. The Dashboard tab can be seen in the following screenshot:
As users, what do we want to see in this monitoring application? We want information at a glance, but with the ability to easily get detailed information. Our primary concerns are the response times of web requests and queries to the database, so we want both these metrics available to us. Let's think about the user interface that supplies this information and what it might look like:
On the Dashboard tab, we're using charts to convey trend information—about both the short-term and the longer term—and this provides our at a glance view of the data. The top two charts update in real time to show the average response time, whereas the bottom charts show historical trends for comparison. How about getting details on this data?
Also, we've added tabs on the left-hand side of the screen that allow you to switch between log types. In this application, we've just got SQL and Web in addition to the initial Dashboard view, as shown in the following screenshot:
In the main part of the screen, we've got a set of controls to filter the data. The chart and grid underneath will update depending on the results of the filter. This gives the user the ability to view data within a particular date range. It also gives the user the ability to pick the category of detail to drill down.
What sort of categories? It could be extended in future, but here's our current list for the Web tab:
- Location
- Browser
- Type of device
We're displaying information on the web requests in our date range to provide more insight on who is visiting our application. Are we getting lots of visitors from Japan? Are they experiencing unacceptably high response times? Maybe we need to add a server somewhere in Asia to meet their requirements. Are we seeing a lot of tablet users? Do we need to improve our responsive design to better cope with a tablet screen size?
On the SQL front, we've got:
- Query type (select, insert, update, and so on)
- Slowest queries
- Query sources
The first is just general information; you could see whether your application was read-heavy or write-heavy here, which would inform how your technology stack changes over time. The other two go hand in hand, showing the slowest queries and which pages in the application issue most queries.
These metrics are useful to increase transparency in an application. In some cases, they won't be enough to diagnose subtle issues, but they will be invaluable in showing the trends of how your application and users are behaving.