Building Single Pages Applications
Building Single Pages Applications
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
This is transcript of talk I gave on #msswit conference 25 April 2013.
What is SPA?
If you just imagined the pools and saunas and massage rooms, this is, unfortunately, not the thing that I going to talk about. We'll check out new concept of web applications, that are called - Single Page Applications.
From technical perspective SPA means the web application, that being loaded as one HTML page and redraws it's UI without round trip to server. That sounds not so exiting, but we can see that SPA is much more than that.
GMail is canonical example of single page application. It was not the first single page application though, it became very popular and gathered a lot of users. That was probably the first time the masses of people realized new user experience - application that works in browser, behaves similar to application on desktop. So, SPA opened a of new opportunities and abilities for software developers to release and promote their applications in web, which is in common case a much easier task, comparing to desktop applications. And new approach need to be taken to create such applications.
API oriented architecture
Before we jump into SPA details, let's talk about the architecture that would allow to build apps in that way. Popularized by Twitter it's being adopted by many vendors and became kind of default. We are talking about 'API oriented' architecture.
It's quite typically that server and client are communicating through HTTP, using JSON as payload format and relying on REST principles. I'm saying typically, since it's not always the case. Some apps might takes XML and use RPC instead of REST, but that actually doesn't really matter.
How to build Single Page applications?
We have a bunch of technologies, server and client that would allow to do that. ASP.NET MVC, Web API, NancyFX, ServiceStack, Express.js, RoR.. etc, on server and Backbone.js, Knockout.js, Angular.js, Marrionette.js, Durandal.js etc. from client.
It gives a lot of options, actually. All of them have their pro/cons. I've used to use ASP.NET MVC as platform to build open API's and was quite happy with that. Nowadays, I'm using Node.js / Express.js and it works really great, as well.
The truth is, with SPA, the front-end technology plays a bit more significant role. Of course, server still performs important role for authorization, data access, business logic.. but in API oriented architecture is turns to be a kind of CRUD exposed through HTTP.
As for front-end, my experience lies in Backbone.js. Preventing the questions, I would say - Backbone.js is not perfect (as there are nothing perfect in this world). Bare Backbone.js app would require a lot of manual coding, but it would also allows to see some important implementation details that could be good for general SPA understanding.
Server is responsible for two principal things. First, it provides with API. Second, it server the master page (again, it's not always the case, master.html could be places in some static resource server).
As always, it's important to think about scalability. Doesn't matter what technology you pick up, it's able to scale and hanlde more incoming request with given response time is vital.
Scalability is important here, as well. That's a different scalability, though.
... scalability in this case is not the number of users running the code at any given time. It’s the number of features in the system, how those features interact, and how you can start up and shut down and do all these things with these different features so that your application can grow in size, grow in features, and grow in capabilities.
Require.js and AMD
Besides of that, Require.js comes with building/optimization tools, that helps to prepare application to production.
So, the Master html has a reference to Require.js main file, which will be responsible for configuration and initialization of app. This typically includes setup of view state management (ViewManager) and routing (Backbone.Router).
Router, handles in-browser URL change events and notifies about that changes.
The URL change might appear of 2 things: user clicks some href or submits the form with re-direct. The SPA prevents those things. Instead, all
The handler job is to load the application and execute it.
Applications in terms of code, are simple objects with
The responsibility of application is to fetch all required data and intitialize application Main View. The Main view is then passed to a ViewManager, which is responsible to render it and attach to DOM.
Besides of that, application is also 'logical' group of different modules with one goal. Imagine GMail application again - Contacts, Mails, Tasks are different applications. Each application, could have sub applications (with their own data and views).
The rule of thumb, one route one application.
As it's been mentioned about, View Manager is important part of SPA architecture.
It handles the aspects of switching one application (MainView) to another. So, the content of application div is cleared up and than updated with new one. In Backbone.js application, that is particularly important, since besides the DOM update View Manager is responsible to clear up unsubscribe all events that views might be subscribed to, to prevent, so called Zombie View problem.
Main View and Subviews
Not trivial application could contain some complex UI. All complex UI is being divided on many smaller components.
MainView is responsible for whole application UI. It's typical job to instantiate and render all required subviews. It also stores the references for all subviews into some internal data structure, so it's been able to close all them, while main view is closed.
TheMailer - demo application
Here is TheMailer - very simple application that implements all the ideas above. I've created that very quickly and I could not call it completed. At the backend it runs ASP.NET MVC/WebAPI and using Require.js + Backbone.js at front end.
It allows you to view and compose email, as well as some simple management of tasks and contacts.
Under the debugger, it is clear how the application is initialized and starting up, how MainView creates Subviews and how Routing and ViewManager works.
I would call it SPA bare bones. As I mentioned above, using pure Backbone.js is good, since Backbone.js contains all required components which any SPA need (most important it have Backbone.Router).
But I would recommended to check further. If you plan stick to Backbone.js, Backbone.Marionette by Derick Beiley could be really nice option. For Google technologies fans, Angular.JS makes a lot of sense. For ones that liked Caliburn.Micro during WPF programming, could play with new framework Durandal.js by Rob Eisenberg.
SPA is a lot of fun and adventure, welcome in!
Published at DZone with permission of Alexander Beletsky , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.