Extending Office 365: The Developer’s Architectural Guide

Posted on 6/22/2015 @ 8:23 AM in #Community by | Feedback | 1186 views

We are living in interesting times. While the world is speeding along the hyperloop of lightweight cross platform open standards applications, arguably a lot of on-prem SharePoint development is still stuck in a 10 year ago world of WSPs, a very heavy virtual machine, full admin rights etc. Frankly developing for ASPNET5, vs. SharePoint WSP, is heaven and hell. The SharePoint dev story always felt like an afterthought, and huge props to the teams at Microsoft that made fantastic dev tools in Visual Studio for it (And no I don’t mean VSeWSS). Huge props to tools like WSPBuilder also that plugged that gap before the tools were around. Still, you can only put so much lipstick on a pig, the dev story for SharePoint WSPs is still ridiculously bad.

Meanwhile, Microsoft introduced Office 365, and the app, I mean add-in Model. After having tried the app/add-in model, I wrote some thoughts on it. The first was “SharePoint App Model: Rest in peace”, and the second was AppParts suck. Since then, the app model definition has been expanded to include any off server code, and the whole thing has been renamed from “Apps” to “Addins”. I realize it has caused a lot of feelings and commotion, that was never my intent. As some people from Microsoft have tried to play down those issues as “link bait”. Anyway, I stand by what I wrote. There are some core issues with the architecture as it stands today. Asking us to never customize masterpages, not write sandbox solutions, or deliver enterprise class multiplatform apps as iframes is not something that will work.

I don’t make this world, I just live in it. So, given the current constraints and scenarios, I wrote an article around what I am doing to build solutions for both on-prem and the cloud.

The constraints I am faced with are,

  1. People want a consistent dev. story between cloud and on-prem. 99% of the code we write must be portable between cloud and on-prem.
  2. People want very good control on the UX, runtime customizability, and responsive design.
  3. People want CSS and branding consistency far more than chrome control offers.

Luckily solutions exist to all of these issues, in my next article on code-magazine, I have elaborated on my what are my thoughts, and opinions about the dev story for both on-prem and O365 as it sits today. Alongwith code examples, and building simple applications that allow me to meet these goals.

In this article, I talk about the approaches I have used to make 99% of my code work without rewrite or even recompile between on-prem and Office365. How I avoid the chrome control and IFrames based add-in parts, and why do I avoid them. What alternatives exist and what are the tradeoffs. Etc.

I hope you enjoy the article, and I hope it leads to a fruitful discussion that eventually ends up improving the dev story in the cloud AND on prem. I don’t know your world, but in my world a lot of dev work is still on-prem. Even though it is on-prem, people want a painless transition to the cloud.

Sound off but keep it civil:

Older comments..