What’s the Role of the Server in Single Page Applications (SPAs)?

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:


Data Service

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.


Data Caching

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:


    .when('/customers', {
        controller: 'CustomersController',
        templateUrl: '/app/views/customers/customers.html'

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 generated:


    .when('/customers', {
        controller: 'CustomersController',
        templateUrl: '/views/customers'


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 devices.

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?


View Caching

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.

Browser dev tools make it super easy to tweak HTML, CSS, and JavaScript so 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 irresponsible.


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.

comments powered by Disqus


  • Great post Dan. Thanks.

  • So I think a bigger deal needs to be made of the security aspect of SPAs. Not just from an authentication and authorization standpoint but from a business logic standpoint. If your application does business logic (e.g. enforcing order maximums or pricing) on the client side, you are exposing your application to malicious manipulation. All important business rules need to be enforced on the server as well as the client (or maybe just the server). Serious applications can't trust the client.

  • Uriah,

    I completely agree....so much that I decided to add a section titled Security, Security, Security since people new to SPAs or client-side programming may not realize the major security issues there. Thanks for the comments.


  • Thanks to clarify the server role of a SPA, especially the security part. In one of my project (AngularJS + ASP.NET WebAPI) user authentication and authorization will be done by server side and returned token + signature stored in cookie. Even I have some codes to hide views, DOMs in Angular, but I don't think it's secured. Anyone can read/change any values in cookie, Angular and DOM through web dev tool.

  • You forgot or probably do not outlined one vital feature of server without which SPA almost cannot exist (at least SPA where user provides some input) -SERVER SIDE VALIDATION!!!
    Without it your application will be polluted with invalid data quite soon.

  • This is exactly what I was implementing in one of my application. I have user auth component on the server side with roles and premissions. And the application required to load different menu items , page components etc...for eavery user role.

    First I was thinking to do it on the client side as wanted to do server only json requests (as SPA apps right concept), but I found it not so secure as you point it out.

    So I did kind of MM-SPAs, knowing that this is not right concept in terms of data/presentaion separation, but it works very well. And have more controll over user roles and premissions.

    Thanks for clarification :)

  • Kai,

    Great point! I agree with you. While I consider that to be part of the data service mentioned above I didn't explicitly mention that so I'll update it. Thanks for the comment.


  • Thanks for this post. Now, I can have better understanding of security and validation handling with SPA. Thanks again

  • Thanks for this article, it made me feel much better about how my SPA application is structured! I serve up all my views and controllers wrapped around a security layer that ensures certain scripts and content aren't loaded. I can then just reuse the security layer on my CRUD methods to make sure somebody doesn't just guess a save call.

    Another thing I use the server for is I18N - while I've experimented with client side I18N, for particular applications, I've found it to be much simpler to deal with, versus handling it on the client.

  • Can you please do a server-side development / requirment / consideration / Security / Authorization / Authentication course for pluralsight with regards to SPA. That include Asp.net / Web Api / SQL Server / AngularJS+. Thanks and best regards

  • Its amazing magazine with great java script and J query library...great work..

  • In addition to dynamic views one might also load dynamic javascript files. This way View/ViewModels might be customized according to the logged user, to the chosen culture(in case of multi-lingual applications), etc.

    However, I don't agree on the pure Data service role of the server. This make sense only in case there is almost no business layer. In case the business layer is not trivial it must run on the server side for security reasons, and the server can't work anymore as a simple data source.

  • Can you point us to reference code samples of server-side view manipulation.

  • The server will continue to be used for any and all SPA that requires strong security. AFIK There ain't a no such thing as JavaScript Encryption.

  • Granted, security IS very important. If so, then do you know of any existing resources you can point to that show how to properly implement roles, authorization, and authentication in an angularjs/asp.net spa application? There's a Pluralsight course on Angular for the .NET developer, but it does not address this concern, nor do the many angular tutorials out there, unless I am missing something... Any insight would be appreciated!

Comments have been disabled for this content.