For the past several months I’ve been working on a complex app and last month I wrote a post called The SharePoint 2013 App Model is better than Farm Solutions based on my experiences. This post led to much discussion online, in person, and via email. These conversations have made it clear to me that if I want to continue blogging about app architecture I need to provide more detail about my specific architecture.
There is a great deal of confusion and misinformation out there, and I don’t want to get into point-by-point debates based on generalities and assertions. This is especially easy to do when discussing apps because ‘app’ is a meaningless generic term. The architecture discussed here is by no means the only way to build an app. In fact, it has very little in common with a SharePoint hosted app or a provider-hosted app delivered via an app part.
Before I go any further I should remind you that traditional solutions are easier to build and that apps have a learning curve that can’t be discounted. At no time should you take my statement that apps are better as meaning that they are easier to write. Most of the pieces of the architecture I am about to describe are things I won’t have to write again for subsequent apps, however they did take many months of work to design, refine, and build.
I believe that enterprise architectures should have clear operational goals that the system meets that are independent of user facing functionality. I’ve seen first-hand how a good architecture can yield serious competitive advantages. When I first began thinking about sandbox solutions that could be sold to Office 365 users I had a few questions that I wanted the architecture to answer.
- Entitlement – how do I deal with a customer who doesn’t pay but has the solution installed?
- Updateability – how do I keep (hopefully) thousands of instances of the app consistent with each other and how do I push new functionality?
- Other devices – How can I design my code base to allow clients other than SharePoint? Is SharePoint a good platform for application services to a heterogeneous set of client technologies?
These are all concerns of a SaaS vendor more so than concerns applicable to in-house solutions although #2 and #4 could be critical to an in-house app. Either way, if you add these requirements into the mix, all of a sudden a farm or sandbox solution becomes potentially much harder to build and in the case of sandbox, you are dependent on a deprecated technology.
To meet these goals I settled on certain strategies and guidelines based on my previous experience with large distributed systems and with SaaS; yes, I had a life before SharePoint!
Embrace web technologies
This one means that I want to align to the current state of the art for web based systems. I want to use the most common libraries like jQuery and I want to exchange data using JSON. I want to avoid putting UI code into any of my services and keep the UI in the browser.
Minimize technology stack dependencies between subsystems
Pieces of the system should be as atomic as possible and they should have absolutely minimal dependencies on the technology used to implement other subsystems. I should be able to move them around and re-platform them if necessary. Most importantly, the architecture should allow major changes in one subsystem (such as a new version of SharePoint) with minimal impact on the other subsystems.
I dream of success and thousands of clients! I want as much centralized control as possible. Therefore my application services should centralize:
- Business logic
- Data services
This allows me to know when a client is having problems, to push updates as needed, and to handle many different scenarios like trial accounts, notifications specific to a client, and subscription based services. Furthermore, it protects my IP and makes piracy a non-issue.
Ultimately I want to support a variety of client devices and I also want my clients to keep their data so that their information stays secure and private. Therefore the static user interface components, i.e. web pages, are distributed and the data stays in the client’s environment, i.e. in SharePoint lists and libraries.
The following diagram shows the high-level architecture and data flow. Notice that my pages do not talk directly to SharePoint with the exception of list views and the other functionality gained simply by being a page in a SharePoint site. The data layer and application services are in a web role and a worker role in Windows Azure.
You might worry that such a system would incur a big performance penalty. In fact the communication overhead is not significant on Azure. There is very little latency between my Azure services and Office 365. I assume they are on the same network.
App Launch Flow
I wrote earlier about Managing Identity and Context in Low-Trust Hybrid SharePoint 2013 Apps. The mechanism I described requires a certain flow when the user launches an app. This flow is also the key to updating the pieces which are distributed to the client’s site. A conceptual version of this flow is shown below.
Whenever the user launches the app the centralized system checks the version of the user’s installation. If necessary, the app server can make changes or additions to the deployment and add new lists, libraries, or pages. Again, this works with one client or with millions of clients.
Hopefully this post goes a long way to frame the discussion about the pros and cons of apps compared to a farm solution. As I get closer to release of the monster I’ll be showing more concrete examples, but until then, if you need help or training with an app I’d love to hear from you!
Author: Doug Ware