Key takeaways from a SharePoint developer @ #SPC2014


Why this post?

I am sure there will be millions of blog posts summarizing #SPC2014 and the vision of Microsoft on driving the SharePoint community.  This blog post mainly covers new key areas a SharePoint developer should be focusing moving forward.

WSP or App?

Coming from the territory of On-premise/WSP developers I came to this conference with the doubts around WSP vs APP?…On-premise vs Office365…How mature is this app model?…Is this the right time invest my time on app development training or should I buy few more months until SharePoint API’s and app developer community gets more traction.. etc  After few hours in to the first day I realized that the whole conference is themed around app model and I slowly understood why Microsoft thriving us to evolve from WSP to Apps.

Why App?

Though deploying DLL’s in GAC is projected as the major reason for shifting to app model, the real X-factor IMHO is O-Data and REST. Though these terms may sound intimidating,  O-Data and REST protocols are the industry standards for data exchange for quite some time and adopted by fellow software giants such as Google, Facebook etc. Most important feature of REST service is the ability to query any granular element from any O-Data compliant data-source with simple ajax http get/post calls from the browser eliminating any server dependence. Since most of the data sources including SharePoint is O-Data compliant, data can be accessed from outside in a contrasting way to server side solutions where sp webapp worker process do all the heavy lifting. So to isolate the app web worker process and access O-Data services paradigm change to app solution packaging and hosting becomes inevitable.

As my thought process towards open inter-operability standards expanded, its a no-brainer to understand app-model is the game-changer and it opened many doors to integrate SharePoint with other systems. Now being determined to learn app model, I took most of the developer sessions to understand the big-picture of this model.

So the idea is to learn best practices/tips to retrieve the data and present it using the app model:

App model and SharePoint apps

Since Infopath is going to suffer a slow death and list forms are not going to provide rich GUI its all going to be all HTML5 forms to send data to SharePoint. And the days of designing page long HTML forms accompanied with a javascript is gone. Its high time for us to welcome AngularJS. For starters AngularJS  is a open source MVW (Model View Whatever) framework from Google which let us to create dymamic HTML web templates with two way binding. This video is a good reference to understand basic concepts of AngularJS. Outcome of this pattern is extraordinarily expressive, readable, and quick to develop Web forms which will be added as app pages in the app solution.

Microsoft upgraded most of their office 365 REST API’s to get data out of SharePoint online and Exchange online from any platform such as Android/IOS. This link is worth having a look.

So the future SharePoint project life cycle is going to evolve from WSP’s to developing webpages using AngularJS packaged in to an app which is running under different worker process and utilizes Office 365 REST API’s for data transfer.

This post from SharePoint MVP Jeremy Thake explains a little about this model.

Preparing Business Line Apps to integrate with SharePoint:

Now with these changes to SharePoint apps, data providers to SharePoint needs to feed the data via custom REST services. The days of developing web parts/_layouts and calling store procedures directly from data access layers is over now. Data providers such as SQL/Oracle now should be wrapped with REST/ODATA compliant HTTP web services to expose them to browsers/mobile etc. so that CRUD REST calls can be easily made from AJAX JS libraries. ASP.NET Web API is a framework for building web APIs on top of the .NET Framework using MVC patterns.

This solution from SharePoint MVP Scot Hillier is an example of this implementation. Now with data services ready, BCS apps can be used to connect to SharePoint.

Presentation and Mobile support:

Another big gotcha for a developer is to rethink  the UI design strategy to be “Mobile First”. Which means the CSS design process should start from devices to browsers. With the high expectations from the user community for SharePoint sites with interactive and easily available from any device with any form factor. To service such a complex requirement, Responsive Web Design (RWD) is introduced to leverage CSS3 and HTML5.

SharePoint specific RWD frameworks should be adopted to aid such a need.

http://responsivesharepoint.codeplex.com

http://spblueprint.codeplex.com

Follow this blog from Eric Overfield, a leading expert in SharePoint Branding to learn more about this.

Also to help with the CSS design workloads, SASS (Syntactically Awesome StyleSheets) language built on RUBY which compiles into CSS. This enables to use variables, nested rules etc on CSS.

http://dotnet-rocks.com/2014/02/18/an-introduction-to-sass/ 

Summary:

Architecture