Thursday, 14 December 2017

Presentation deck – Best bits of Azure for the Office 365/SharePoint developer

This is post 2 of 2 to publish the slide decks for presentations I’ve given recently, in particular at the European SharePoint Conference 2017 held in Dublin. See also:

Presentation deck – Pitfalls in SPFx development

As with my other post, the slide deck is embedded at the bottom of this post. There’s no way for me to convey the demos easily, but the slides themselves hopefully have some good reference information. When you start to consider some of the different scenarios in even lightweight extensions to Office 365/SharePoint, it’s clear how useful Azure is:

What? How?
Do something on a schedule Put code in Azure Web Jobs/Functions
Build apps (Office 365 app/SP provider-hosted add-in) Deploy app files to an Azure app
SharePoint site provisioning Deploy PnP Partner Pack (or PnP Core with some calling code) to Azure
Run code on a button click Use Azure Functions + JavaScript
Store data not suited to SP lists Use Azure SQL Database
Store files for my app Use Azure BLOB storage (and CDN if appropriate)
Implement SharePoint web hooks Use Azure Queues and Functions
Implement authentication on a custom web app Implement Azure Active Directory (AAD) auth

The highlighted scenarios are ones I demo’d, with the last one actually being a demo of a real-world solution we built which touches on queues, web jobs, BLOB storage, CDN and more.

Otherwise the main topics are:

  • Azure web apps
    • Lots of cool features you might overlook here, including Deployment Slots and Testing in Production. In other words, it’s much more than simple web-hosting that you might get from the days of hosting IIS yourself..
    • Variety of ways to deploy files there – from the Kudu interface which is similar to dragging/dropping files into a SharePoint document library, to publishing from Visual Studio, to WebDeploy, to auto-sync from your source control (VSTS, GitHub etc.)
  • Azure App Insights
    • Another unsung hero of Azure? I’ve discussed this in a couple of posts recently, including Use Azure App Insights to track events in your app/web part/provisioning code. I love the idea of finding out how often a particular web part is running, or if a particular tab is being clicked in your app – and it’s really simple to put this kind of stuff in place too. App Insights also has great tools for querying your logs in a SQL-like way, and also for configuring alerts (e.g. if the home page takes longer than 5 seconds to load from the client-side). Take a look!
  • Azure Functions
    • If you’re an Office 365 developer and you haven’t implemented some code in an Azure Function yet, I think it’s only a matter of time :) I have a slide which compares to Azure web jobs, but overall Functions can be used in so many more scenarios – including things like a button click in a web part or PowerApp, or perhaps a call out from a Flow or the Site Designs model for site provisioning (via a Queue Trigger)
    • I also talk about how Azure Functions should typically be secured with AAD auth in the real world. I demo’d an SPFx web part which uses SPO cookie auth as an alternative to adal.js or similar – this has some advantages to the current arrangement (of adal.js), including the fact that multiple web parts on the same page don’t need to sign-in separately
    • It’s also worth understanding how far the Visual Studio tooling for Functions has advanced. Sure, VS Code is the cool kid for many coding scenarios these days, but for C# functions, VS 2017 is actually stronger I feel – some info on this:
      COB options for Azure Functions - CSharp
  • Azure SQL Database
    • The main point here is to stop storing things in SharePoint that should be in SQL :) SP devs who haven’t touched SQL for years shouldn’t be scared of Azure SQL – it’s really easy to get started, and you can run databases up to 20GB for free
    • Also, be aware that identity in the SQL world has been updated for the cloud. You can now use Azure Active Directory accounts to authenticate, including from tools such as SQL Management Studio and Visual Studio Server Explorer
  • ARM templates
    • ARM templates offer an alternative to lots of button clicking and manual configuration in the Azure portal – perfect for those things that will be deployed to multiple Office 365 tenancies/Azure subscriptions, where you want repeatability
  • Azure Queues (and triggers)
    • Queues are a great building block to support things you might do in code. Any time you need some separation or some long-running processing, a queue is often a nice pattern to use – one thing puts something on the queue, and something called a QueueTrigger is used to point to some code which does the long-running thing (e.g. create a SharePoint site). As mentioned previously, the new Site Designs model for site provisioning will use this, and so do SharePoint web hooks.
    • In terms of what your code might be, Azure Functions and Azure web jobs are common – both work with QueueTrigger as you might expect

As before, hopefully there are some useful nuggets in here which are useful to you!

    Slide deck:

    Tuesday, 5 December 2017

    Presentation deck – Pitfalls in SPFx development

    This is post 1 of 2 to publish the slide decks for presentations I’ve given recently, in particular at the European SharePoint Conference 2017 held in Dublin. See also:

    Presentation deck – Best bits of Azure for the Office 365 Developer (to be published on Dec 08 2017)

    Unfortunately, I never think the slide deck alone conveys all of the information of a conference session, since it’s the demos which are often the most valuable part. Still, I try to assemble slides which have useful reference information, so hopefully this will be useful to someone. The full slide deck is embedded from SlideShare at the bottom of this post. The main topics I discuss here are:

    • Versioning and dependency issues
      • The need to ensure you use --save or --save-exact when adding libraries with npm install (so that they are recorded in your package.json file, and other developers on the team can successfully build from source control)
      • Semantic versioning, including caret and tilde symbols in version numbers
      • The need to run npm shrinkwrap for each release of your code
      • [NOTE – some of this changes in npm 5, which automatically does a --save when doing an install, and also automatically generates a package-lock.json file (similar to npm-shrinkwrap.json. But for now, npm 5 is not officially supported in the SharePoint Framework (SPFx) and so these points remain important)
    • Re-use of existing JavaScript code
      • You might choose to wrap such code in a module if it is not already – this provides a more formal method in TypeScript/JavaScript of sharing code (e.g. library code)
      • Once you have a module, you can look at options such as npm install [filepath], npm link or using a private hosted npm repository provided by npm private packages or Visual Studio Team Services Package Management
    • Office UI Fabric
      • Use of Fabric Core and the Fabric React components – using the Core styles is much simpler in version 1.3.4 onwards of SPFx, where the sp-office-ui-fabric-core package is referenced and the SCSS styles use mixins to reference the styles in your custom styles
      • When using the Fabric React components, you should typically ensure you use static linking in your import statements e.g. import { Button, ButtonType } from 'office-ui-fabric-react/lib/Button';
      • See Using Office UI Fabric Core and Fabric React in SharePoint Framework for more information on this
    • Calling the Microsoft Graph and/or custom APIs (e.g. an Azure Function)
      • All of these resources are likely to be secured with AAD
      • GraphHttpClient is currently of limited use..
      • you will most likely need adal.js if calling from the client side, or ADAL.NET if calling from the server side
      • An alternative to adal.js for a custom web API/Azure Function, is the approach which leverages the SharePoint Online authentication cookie to pass credentials to your API (using the “credentials”: “include” header to pass across domains) – I think this is a useful approach and one of my demos covered this (video at
      • I use this slide to give an overview of the two approaches:

      • Also note that soon, it will be possible to call your custom APIs by specifying additional AAD app registrations that can be called from SPFx without additional consent. This will simplify things significantly, and mean that your SPFx web parts/extensions will no longer need a sign-in button/process just to be able to call downstream resources
    • Deployment
      • Remember that the default SPFx behaviour is for any 3rd party libraries you add to be bundled into your web part – this increases your bundle size, and can be a particular problem when you have multiple web parts/extensions all using the same library (and Office UI Fabric can be a big culprit here!)
      • Another “by default” thing to remember is that each web part/extension you build gets it’s own bundle – the config.json file is what controls this
      • Where possible, 3rd party libraries should be externalised to a CDN..
      • ..and if that isn’t possible, consider SPFx component bundles as a way to avoid having a library duplicated amongst all your web parts. In the case where you have 5 web parts on a page all using the same library, if you don’t externalise or use component bundles performance will suffer for first-time page loads

    Hopefully there’s some useful information in here, and I’ll most likely expand on some of these points in future articles. Here’s the slide deck:

    Slide deck: