Lessons Learned from the #SPShire Project
I’m thrilled to be part of an early adopter project building a new intranet for Shire Pharmaceuticals based on the forthcoming SharePoint Communication Sites. Shire is an exciting and innovative company, and the team includes a number of my fellow Microsoft MVP’s as well as teammates from BlueMetal. Last week Microsoft broadcast a webinar from the Boston MTC featuring a cross-section of the development team. Microsoft’s Mark Kashman promised we’d post some of the lessons learned in the project, and this is one of those postings.
The lessons in this blog series are:
- Previewing and Opening Office Documents from the SharePoint Framework
- Using the OneDrive File Picker in SharePoint Framework Solutions
- Creating Reusable React Components for SharePoint Framework Solutions
This project on github contains the sample solution for all three articles.
In old-school SharePoint, if you wanted to run some custom code in a web part, workflow, form, or event handler, you wrote either a sandboxed or a farm solution. Neither of these are supported in SharePoint Online. So what are developers supposed to do when they need to run some code somewhere other than the web browser? How can they run code in the background, elevate permissions, or fill gaps in the “out of the box” configuration options?
The modern answer is Azure Functions. It’s a much better sandbox than SharePoint used to have, yet, like a sandboxed solution, you don’t have to worry about where to put it. Just choose what will trigger your function, such as a web service request, web hook, Service Bus message, or a time schedule. Then pop in your code and you’re good to go. They call it “serverless” computing, but there are servers somewhere! You just don’t need to worry about it.