I’ve been doing a lot of AngularJS consulting and training lately and have been asked
one particular question over and over: “What’s the role of the server in Single
Page Applications (SPAs)”? Regardless of what SPA framework you use (AngularJS, Ember, Durandal, etc.) every SPA
framework out there relies on some type of service (RESTful or otherwise) to
serve and process data. That’s the obvious role that servers can play with SPAs.
What’s not quite as obvious are the other roles that the server can play as a
SPA interacts with it. Here are a few ideas about roles that a server can play when building SPAs.
This is the role that most people think of the server playing with SPAs and
definitely the most common role. The server typically exposes a RESTful service
to SPA clients to make it easy to GET, PUT, POST, or DELETE data. This can be
done using Node.js, ASP.NET Web API, PHP, cloud services like Firebase, and many
other frameworks using HTTP, Web Sockets, or another technique. As mentioned
earlier, this is the most obvious role played by the server when building SPAs.
In addition to exposing data, the data service is also responsible for
providing security as required by a given application.
Some applications consume data that doesn’t change very frequently on the
server. This type of data can often be shared across users (product codes,
countries, states, departments, locations, etc.). Servers are great at caching
data so that queries to the data store are minimized. Whether you’re using
Node.js, ASP.NET MVC, PHP, or one of the many other server-side frameworks, you
more than likely have access to caching functionality that can increase the
scalability of your application significantly. It’s something that I always try
to plan for as I think through the role of the server in SPAs and other types of
applications. Cache is king (when used appropriately)!
Serving Dynamic Views
Many SPAs load static HTML views from the server that are then processed on the
client-side. For example, AngularJS allows views to be associated with routes so
that the view can be loaded at runtime when a given route is processed. Here’s
an example of defining a route and view (the templateUrl value) using AngularJS:
While static HTML views work in many scenarios, there are other scenarios
where you may want to load some of the data during the view request, fill in a
part of the view with the data, and then send it down to the client for further
processing. Why? Doing that can eliminate one or more HTTP calls from the
browser to the server to retrieve data (via Ajax, web sockets, etc.). The route
shown earlier may be changed to the following to allow for a dynamic view to be
True, this technique will cause the number of bytes sent from the server to
the client to increase, but sometimes reducing the number of HTTP calls can
result in a nice performance boost – especially when it comes to mobile
While dynamically generating views and pre-populating them with some of the
data certainly isn’t appropriate for every type of SPA out there, some SPAs may
benefit from utilizing this type of server-side functionality. Some people may
argue that this approach is against the true nature of SPAs but I would argue
that every application is unique and there’s no such thing as one size fits all.
Pre-filling SPA views with data on the server may be beneficial in some
scenarios. Who says that you can’t create what I like to call “mixed mode SPAs”
(MM-SPAs….OK I’ll admit that doesn’t exactly role off the tongue :-)) where the
server does more than simply serve up data, scripts/styles, and static views?
In addition to data caching, the server may also be used to cache HTML views
that are retrieved by a SPA. As mentioned earlier, views may be dynamically
generated on the server, and in situations where data doesn’t change often and
can be shared across users, the views and data may be cached by the server to
allow them to be served in a more efficient and scalable manner.
Once views reach the client they can also be cached there of course for
scenarios where a fresh view isn’t required each time a route is triggered.
Security and Dynamic Views
Security is a key part of many applications. SPAs that load static HTML views
from the server more than likely handle security on the client-side (you
of course can’t rely on the client for any type of true security) as
well as through the data service exposed by the server (where the real
security checks should occur). What if your HTML view needs to load
specific sections of a view dynamically based upon roles, claim sets, or other
types of security constructs?
The server can once again be used to dynamically generate the view based upon
specific security requirements. That way HTML fragments aren’t sent down to the
client only to be hidden by the SPA framework based upon a user’s role (and
easily unhidden by a power user using dev tools). Only the view content that the
authenticated and authorized user should see based upon their current
roles/permissions is sent down to the browser. I think this is definitely an
area where mixed mode SPAs can be very appropriate depending upon the needs and
requirements of the application.
Security, Security, Security
I can’t emphasize enough how important the role of the server is when it
comes to security. While you can certainly send down roles, permissions, and
other security items to the client so that data or HTML fragments can be
shown/hidden as appropriate in views, it’s critical that the server validates
everything coming back to it.
storing a user’s security roles on the client (as just one example) is fine but
every request to the server should be validated on the server-side to ensure
that the user really does have a given role/permission and can perform a
specific action. Otherwise, a hacker can easily compromise your application and
data by simply changing client-side variables. Using client-side code to secure
applications (SPA or otherwise) is not a good way to go and arguably quite
I normally consider validation to be part of the overall data service component
mentioned above but it’s important enough to call it out separately. As with
client-side security, client-side validation is a frail solution that can’t
stand on its own. All validation of SPA data has to be validated on the server
to ensure that the client-side code, and data haven’t been tampered with.
Is this a complete list of all the ways a server can be used with SPAs? Of
course not – this is simply a few things I’ve been thinking about as I’ve
interacted with different companies building SPAs. If you have additional ways
that you’re using the server with SPA applications leave a comment.
Single Page Applications (SPAs) are great and can provide a unique user
experience when built properly. But, switching to SPAs doesn’t mean that all of
your server-side skills have to be thrown out the window.