This chapter serves as a primer of knowledge. With this, you will become aware of all the terms, patterns, and practices applied in the book. Also, you will learn about the tools, libraries, and frameworks being used and what their use cases are. More importantly, you will find out why you should be performing these different things and, in particular, why you are using SignalR, and how the methods you employ will naturally find their way into your software.
In this chapter, the following topics will be covered:
Walk-through architectural patterns
Messaging—what is it?
Decoupling for scale—why and how?
Frontend patterns—also back to decoupling
Twitter Bootstrap—using it to make things look better
SignalR—what is it built of and how does it all come together?
By asking where are we coming from, I'm not trying to ask an existential question that dates back to the first signs of life on this planet. Rather, we are looking at the scope of our industry, and what has directed us all the way to where we are now and how we create software today. The software industry is very young and is constantly moving. We haven't quite settled in yet like other professions have. The rapid advances in computer hardware present opportunities for software all the time. We find better ways of doing things as we improve our skills as a community. With the Internet and the means of communication that we have today, these changes are happening fast and frequently. This is to say that collectively, we are changing a lot more than any other industry. With all this being said, a lot of these changes go back to the roots of our industry. They seek back as if we could now do things right as they were intended in the first place, only in a slightly modified version with a few new techniques or perspectives. Computers and software are the tools meant to solve problems for humans, and often in the line of business applications that we write; these tools and software are there to remove manual labor or remove paper clutter. The way these applications are modeled is therefore often closely related to the manual or paper version, not really modeling the process or applying the full capability of what the computer could do to actually improve the experience of the particular process.
Back in the early days of computing, computers lacked CPU power and memory. They were expensive, and if you wanted something powerful, it would fill the room with refrigerator-sized computers. The idea of a computer on each desk, at least a powerful one, was not feasible. Instead of delivering rich computers onto desks, the notion of terminals became a reality. These were connected to the mainframe and were completely stateless.
The entirety of each terminal was kept in the mainframe, and the only thing transferred from the client was user input and the only thing coming back from the mainframe was any screen updates.
The previous methods of thinking established the pattern for software moving through the decades. If you look at web applications with a server component in the early days of the Web, you'll see the exact same pattern: a server that keeps the state of the user and the clients being pretty less; this being the web browser. In fact, the only thing going back and forth between them was the user input from the client and the result in the form of HTML going back.
Bringing this image really up to speed with the advancement of AJAX, the image would be represented as shown in the following diagram:
Of course, by skipping three decades of evolution in computing, we are bound to miss a few things. However, the gist of most techniques has been that we keep the state on the server and we have to go from the client in the sense of request, be it a keystroke or a HTTP request, before receiving a response. At the core of this sits a network stack with capabilities beyond what the overlying techniques have been doing. In games, for instance, the underlying sockets have been used much more in order for us to be able to actually play multiplayer games, starting off with games on your local network to massive multiplayer online games with thousands of users connected at once. In games, the request/response pattern will not work as they yield different techniques and patterns. We can't apply all the things that have been achieved in games because a lot of it is based on approximation due to network latency. However, we don't have the requirements of games either to reflect the truth in an interval of every 16-20 milliseconds. Accuracy is far more important in the world of line of business application development where it needs to be constantly accurate. The user has to trust the outcome of their operations in the system. Having said this, it does not mean that the output has to be in synchrony. Things can eventually be consistent and accurate, just as long as the user is well informed. By allowing eventual consistency, one opens up a lot of benefits about how we build our software and you have a great opportunity to improve the user experience of the software you are building, which should be at the very forefront of your thinking when making software.
Eventual consistency basically means that the user performs an action and, asynchronously, it will be dealt with by the system and also eventually be performed. When it's actually performed, you could notify the user. If it fails, let the client know so that it can perform any compensating action or present something to the user. This is becoming a very common approach. It does impose a few new things to think about. We seldom build software that targets us as developers but has other users in mind when building it. This is the reason we go to work and build software for users. The user experience should, therefore, be the most important aspect and should always be the driving force and the main motive to apply a new technique. Of course, there are other aspects to decision making (such as budget) as this gives us business value, and so on. These are also the vital parts of the decision-making, but make sure that you never lose focus on the user.
How can we complete the circle and improve the model and take what we've learned and mix in a bit of real-time thinking? Instead of thinking that we need a response right away and pretty much locking up the user interface, we can send off the request for what we want and not wait for it at all. So, let the user carry on and then let the server tell us the result when it is ready. However, hang on, I mentioned accuracy; doesn't this mean that we would be sitting with a client in the wrong state? There are ways to deal with this in a user-friendly fashion. They are as follows:
For simple things, you could assume that the server will perform the action and just perform the same on the client. This will give instant feedback to the user and the user can then carry on. If, for some reason, the action didn't succeed on the server, the server can, at a later stage, send the error related to the action that was performed and the client can perform a compensating action. Undoing this and notifying the user that it couldn't be performed is an example. An error should only be considered an edge case, so instead of modeling everything around the error, model the happy path and deal with the error on its own.
Another approach would be to lock the particular element that was changed in the client but not the entire user interface, just the part that was modified or created. When the action succeeds and the server tells you, you can easily mark the element(s) as succeeded and apply the result from the server. Both of these techniques are valid and I would argue that you should apply both, depending on the circumstances.
What does this all mean and how does SignalR fit into all this?
SignalR goes a step further by representing an abstraction that gives you a persistent connection between the server and the client. You can send anything to the server and the server can at any time send anything back to the client, breaking the request/response pattern completely. We lose the overhead of the regular request or response pattern of the Web for every little thing that we need to do. From a resource perspective, you will end up needing less from both your server and your client. For instance, web requests are returned back to the request pool of ASP.NET as soon as possible and reduce the memory and CPU usage on the server.
By default, SignalR will choose the best way to accomplish this based on the capabilities of the client and the server combined. Ranging from WebSockets to Server Sent Events to Long Polling Requests, it promises to be able to connect a client and a server. If a connection is broken, SignalR will try to reestablish it from the client immediately.
Although SignalR uses long polling, the response going back from the server to a client is vastly improved rather than having to do a pull on an interval, which was the approach done for AJAX-enabled applications before.
You can force SignalR to choose a specific technique as long as you have requirements that limit what is allowed. However, when left as default, it will negotiate what is the best fit.
As in any industry, we have a language that we use and it is not always ubiquitous. We might be saying the same thing but the meaning might vary. Throughout the book, you'll find terms being used in order for you to understand what is being referred to; I'll summarize what hides behind these terms mean.
A message in computer software refers to a unit of communication that contains information that the source wants to communicate to the outside world, either to specific recipients or as a broadcast to all recipients connected now or in the future. The message itself is nothing, but a container holding information to identify the type of the message and the data associated with it. Messaging is used in a variety of ways. One way is either through the Win16/32 APIs with WM_* messages being sent for any user input or changes occurring in the UI. Another is things affecting the application to XML messages used to integrate systems. It could also be typed messages inside the software, modeled directly as a type. It comes in various forms, but the general purpose is to be able to do it in a decoupled manner that tells other parts that something has happened. The message and its identifier with its payload becomes the contract in which the decoupled systems know about. The two systems would not know about each other.
With your message in place, you want to typically send it. Publish/subscribe, or, as it is known in shorthand "PubSub", is often what you're looking for. The message can be broadcasted and any part of your system can subscribe to the message by type and react to it. This decouples the components in your system by leaving a message for them, and they are unaware that they are direct to each other. This is achieved by having a message box sitting in the middle that all systems know about, which could be a local or global message box, depending on how your model thinks. The message box will then be given message calls, or will activate subscriptions, which are often specific to a message type or identifier.
Over the years, we've had all kinds of message boxes. In Windows, we have something called a message queue, which basically also acts as a message box. In addition, there are things such as service buses that pretty much do the same thing at the core as well. The notion of having something published and something else subscribed is not new.
The message box can be made smarter, which, for instance, could be by persisting all messages going through so that any future subscribers can be told what happened in the past. This is well presented by the following diagram:
There are quite a few paradigms in the art of programming and it all boils down to what is right for you. It's hard to argue what is right or wrong because the success of any paradigm is really hard to measure. Some people like a procedural approach to things where you can read end-to-end how a system is put together, which often leads to a much coupled solution. Solutions are things put together in a sequence and the elements can know about each other. The complete opposite approach would be to completely decouple things and break each problem into its own isolated unit with each unit not knowing about the other. This approach breaks everything down into more manageable units and helps keep complexity down. It really helps in the long term velocity of development and also how you can grow the functionality. In fact, it also helps with taking things out if one discovers one has features that aren't being used. By decoupling software and putting things in isolation and even sprinkle some SOLID on top of this (which is known as a collection of principles; this being the Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle).
You can find more information about this at http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf.
By applying these practices with decoupling in mind, we can:
Make it easier to scale up your team with more developers; things will be separated out and responsibilities within the team can be done so as well.
Make more maintainable solutions.
Take resource hungry parts of your system and put them on separate servers; something that is harder to accomplish if it all is coupled together.
Gain more flexibility by focusing more on each individual parts and then compose it back together any way you like.
Make it easier to identify bottlenecks in isolation.
Have less chance of breaking other parts of the system when fixing or expanding your code.
Gain higher development pace.
This might be a bold claim, but you could encounter fewer bugs! Or at least, they would be more maintainable bugs that sit inside isolated and focused code, making it easier to identity and safer to fix.
The ability to publish messages rather than calling concrete implementations becomes vital. These become the contracts within your system.
This book will constantly remind you of one thing: users are a big part in making this decision. Making your system flexible and more maintainable is of interest to your users. The turnaround time to fix bugs along with delivering new features is very much in their interest. One of the things I see a lot in projects is that we tend to try to define everything way too early and often upfront of development, taking an end-to-end design approach. This often leads to overthinking and often coupling, making it harder to change later on when we know more. By making exactly what is asked for and not trying to be too creative and add things that could be nice to have, and then really thinking of small problems and rather compose it back together, the chance of success is bigger and also easier to maintain and change. Having said this, decoupling is, ironically enough, tightly coupled with the SOLID principles along with other principles to really accomplish this. For instance, take the S in SOLID. This represents the Single Responsibility Principle; it governs that a single unit should not do more than one thing. A unit can go all the way down to a method. Breaking up things into more tangible units, rather than huge unreadable units, makes your code more flexible and more readable.
Techniques that repeat can be classified as patterns; you probably already have a bunch of patterns in your own code that you might classify even as your own patterns. Some of these become popular outside the realms of one developer's head and are promoted beyond just this one guy. A pattern is a well-understood solution to a particular problem. They are identified rather than created. That is, they emerge and are abstracted from solutions to real-world problems rather than being imposed on a problem from the outside. It's also a common vocabulary that allows developers to communicate more efficiently.
A popular book that aims to gather some of these patterns is Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Professional.
You can find a copy at http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612.
We will be using different patterns throughout this book, so it's important to understand what they are, the reasons behind them, and how they are applied successfully. The following sections will give you a short summary of the patterns being referred to and used.
MVC was first introduced by a fellow Norwegian national called Dr. Trygve Reenskaug in 1973 in a paper called Administrative Control in the Shipyard (http://martinfowler.com/eaaDev/uiArchs.html). Since then, it has been applied successfully in a variety of frameworks and platforms. With the introduction of Ruby on Rails in 2005, I would argue the focus on MVC really started to get traction in the modern web development sphere. When Microsoft published ASP.NET MVC at the end of 2007, they helped gain focus in the .NET community as well.
The purpose of MVC is to decouple the elements in the frontend and create a better isolated focus on these different concerns. Basically, what one has is a controller that governs the actions that are allowed to be performed for a particular feature of your application. The actions can return a result in the form of either data or concrete new views to navigate to. The controller is responsible for holding and providing any state to the views through the actions it exposes. By state, we often think of the model and often the data comes from a database, either directly exposed or adapted into a view-specific model that suits the view better than the raw data from the database. The relationship between model, controller, view, and the user is well summarized in the following diagram:
With this approach, you separate out the presentation aspect of the business logic into the controller. The controller then has a relationship with other subsystems that knows the other aspects of the business logic in a better manner, allowing the controller to only focus on the logic that is specific to the presentation and not on any concrete business logic but more on the presentation aspect of any business logic. This decouples it from the underlying subsystem and thus more specialized. The view now has to concern itself with only view-related things, which are typically HTML and CSS for web applications. The model, either a concrete model from the database or adapted for the view, is fetched from whatever data source you have.
For more information, visit http://www.codeproject.com/Articles/100175/Model-View-ViewModel-MVVM-Explained.
MVVM was presented by Martin Fowler in 2004 to what he referred to as the Presentation Model (which you can access at http://martinfowler.com/eaaDev/PresentationModel.html).
The ViewModel is a key player in this that holds the state and behavior needed for your feature to be able to do its job, without it knowing about the view. The view will then be observing the ViewModel for any changes it might get and utilize any behaviors it exposes. In the ViewModel, we keep the state, and as with MVC, the state is in the form of a model that could be a direct model coming from your data source or an adapted model more fine-tuned for the purpose of the frontend.
The additional decoupling, which this model represents, lies within the fact that the ViewModel has no clue to any view, and in fact should be blissfully unaware that it is being used in a view. This makes the code even more focused and it opens an opportunity of being able to swap out the view at any given time or even reuse the same ViewModel with its logic and state for second view.
The relationship between the model, view, viewmodel, and the user is summarized in the following diagram:
We will not be doing much from scratch in this book as it does not serve our purpose. Instead, we will be relying on third-party libraries and frameworks to do things for us that don't have anything to do with the particular thing we will perform. The range of libraries will be big and some of these represent architectural patterns and decisions sitting behind them. Some of these are in direct conflict with each other and for consistency in your code base, you should pick one over the other and stick to it. The chapters in this book will make it clear what I consider as conflict and why and what libraries are right for you, whereas your architecture is something you will have to decide for yourself. This book will just show a few of the possibilities.
$, followed by a dot, and then a function to perform. It turns out that this is not true. jQuery just happens to be one of the most popular libraries out there when performing web development. It puts in place abstractions for parts that are different between the browsers, but most importantly, it gives you a powerful way to query the Document Object Model (DOM) as well as modify pick it as your application runs. A lot of the things jQuery has historically solved are now solved by the browser vendors themselves by being true to the specifications of the standards, along with the standards. Its demand has been decreasing over the years, but you will find it useful if you need to target all browsers and not just the modern ones. Personally, I would highly recommend not using jQuery as it will most likely lead you down the path of breaking the SOLID principles and mixing up your concerns.
SignalR has a dependency on jQuery directly, meaning that all the web projects in this book will have jQuery in them as a result. The part of jQuery being used is the communication stack (anything else is not used). There are projects out there that aim towards trimming jQuery. You might find something that only holds the communication part of jQuery, reducing the payload dramatically, since I do not recommend using jQuery for DOM manipulation.
Microsoft's web story consists of two major and different stories at the root level. One of these is the story related to web forms that came with the first version of the .NET Framework back in 2002. Since then, it has been iteratively developed and improved with each new version of the framework. The other is the MVC story, which was started in 2007 with a version 1 release in 2009 that represents something very different and built from the ground up from different concepts than found in the web forms story. In 2014, we saw the release of version 5 with quite a few new ideas, making it even simpler to do the type of decoupling one aims for and also making it easier to bring in things (such as SignalR). We will use ASP.NET MVC for the first samples, not taking full advantage of its potential, but enough to be able to show the integration with SignalR and how you can benefit from it.
It seems that over the last couple of years, you can pretty much take any noun or verb and throw a JS behind it, Google it, and you will find a framework at the other end of it. All these frameworks often play as a part of the puzzle. Google introduced AngularJS a couple of years ago to cover more than just a little part of the puzzle, but it rather provides a broader perspective on client-side development on the Web. AngularJS consists of a core and modules that cover different aspects. With AngularJS, you get the opportunity to separate your code into smaller parts, promoting separation and lending itself to MVC and to a certain extent MVVM. Throughout this book, we will be using Angular for the web solution.
In the interest of saving time and focusing more on code, we will "outsource" the design in this book and layout to Twitter Bootstrap (which you can access at http://getbootstrap.com). Bootstrap defines a grid system that governs all layouts and it also has well-defined CSS to make things look good. It comes with a predefined theme that looks great, and there are other themes out there if you want to change the themes.
You can use the community edition of Visual Studio 2013 if you don't have a license to Visual Studio 2013 professional or higher. It can be downloaded from http://www.visualstudio.com/.
In the interest of saving space in the book, the description of how to use NuGet sits here and only here. The other chapters will refer back to this recipe.
If you need to install NuGet first, visit http://www.nuget.org to download and install it. Once this is done, you can use NuGet by following these steps:
To add a reference to a project, we start by right-clicking on References of your project and selecting Manage NuGet Packages..., as shown here:
Next, select Online and enter the name of the package that you want to add a reference to in the search box. When you have found the proper package, click on the Install button, as shown in the following screenshot:
In some cases, we will need a specific version of a file. This is not something we can do through the UI, and we will need the Package Manager Console. To specify a specific version of a package, if needed, the syntax of the command in the Package Manager Console is as follows:
install-package <package-name> -version <package-version>
Following this, go to TOOLS and then NuGet Package Manager. Click on Package Manager Console, as shown here:
You now have a backdrop of knowledge, if you didn't already know it all. We explained the terminology in this chapter so that the terms will be clear to you throughout. It's now time to get concrete and actually start applying what we've discussed. Although this chapter mentions quite a few concepts and they might be new to you, don't worry as we'll revisit them throughout the book and gain more knowledge about them as we go along. The next chapter will start out with a simple sample, showing the very basics of SignalR so that you get the feeling of what it is and how its APIs are. It will also establish the basics of the project that we will be working on throughout this book, with ASP.NET and AngularJS throwing bootstrap into the mix as well.