Apps for SharePoint and modern web applications

  In a previous post I mentioned  a couple of improvements that the new "apps for SharePoint" model brings for the wider web development community. After developing a couple of web applications using this model I want to elaborate on the new technologies and practices that it made possible.

  First a quick overview of the new development model. This model does not use the SharePoint server side libraries and it does not require to develop your application on a computer with SharePoint installed. It introduces two new types of applications for SharePoint:

• one is a collection of web pages with no server-side code behind. You can only use HTML, CSS and JavaScript to build your user interface and for application logic. This application will be deployed directly to and hosted by SharePoint.
• one is a standalone web application that can use any technology(client or server side) to render the user interface and provide functionality. You have to handle the deployment of the web application alongside SharePoint or a standalone/remote server if you use the "provider-hosted" option. You can also deploy to Windows Azure if you use the "auto-hosted" option.

  Both types of applications can expose "app parts" for SharePoint which are similar with classic SharePoint web parts and/or provide an immersive experience where it builds all the user interface. I will only discuss about the "provider-hosted" web application in its incarnation as a .NET implementation.

  In Visual Studio 2012 the "app for SharePoint" project wizard creates an ASP.NET Web Forms application and adds a reference to the "App for SharePoint Web Toolkit" package that is responsible for integration with SharePoint. 

  You can change the default behaviour and switch to ASP.NET MVC by adding the relevant packages and slightly modifying the project structure(in Visual Studio 2013 you can create an ASP.NET MVC application from the project wizard). At this point your SharePoint application has become an ASP.NET MVC application that is easier to test and closer to a web application rather than a web site.

  Speaking of testability you can now move all the interactions with SharePoint behind an interface making these easier to mock or simulate. You can debug and test your application without any SharePoint server available which is a useful and important change from the previous development model.

  I was able to move one step further than ASP.NET MVC and use a JavaScript client-side framework for buiding most of the user interface. The main driver for this was the need to be able to build "SharePoint-hosted" applications which have a requirement for HTML, CSS and JavaScript.
  For my first project I used a JavaScript framework based on the MVVM pattern but I soon discovered its limitations like verbose code for databinding, proliferation of string based html templates and making it too easy to mix application logic code with user interface generation code.
  In my next project I used AngularJS as my client side framework and this helped me to:

• reduce the JavaScript code size dramatically;
• keep all user interface code in clean, nicely formatted and easy to read html files;
• have a very clear separation between user interface code and the rest of the code;
• test JavaScript code a lot easier. 

  I have extensively used its companion libraries from the AngularUI project and I was able to employ native Bootstrap directives and simplify all the user interface building tasks. AngularJS has great support for RESTful web services and this plained nicely with my server side code. I was very impressed with the power of this framework and it saved a lot of time and effort overall.
 The user interface has built using a single ASP.NET MVC view to render a web page skeleton and handle the CSS and Javascript assets. It allowed AngularJS to take over and render the main content of the page and handle all navigation events. I hope to cover this aspects on a separate blog post soon.

  On the server side I have used the ServiceStack web services framework to create RESTful endpoints and this allowed me to reduce a lot of my development costs compared to ASP.NET Web Api. As ServiceStack it is very testable I had a good coverage for my server side code(see my previous post for a brief overview of ServiceStack).

  Switching to the "apps for SharePoint" application model allowed me to used modern web frameworks, build more testable and tested code and reuse a lot of tools and techniques employed for standalone web applications. It made it easy to introduce web developers to this type of applications as now the main requirement is a good command of modern web development technologies: HTML, CSS, JavaScript and RESTful web services.

NOTES:

• My presentation slides on this subject can be found here;
• Further details on the "apps for SharePoint" model can be found here.