SPFx series: De geschiedenis van SharePoint-ontwikkeling

Welkom bij de SPFx Series! In deze blogserie duiken we diep in het SharePoint Framework (SPFx), een krachtige toolset voor het bouwen van moderne, dynamische oplossingen in SharePoint en Microsoft 365. In deze blogpost duiken we in de geschiedenis van SharePoint-ontwikkeling.

Webonderdelen als Farm-oplossingen ~ 2007

In het verleden was er alleen SharePoint On-Premise; een cloudomgeving was er niet, want de eerste introductie van SharePoint Online was pas in 2012. Er was alleen SharePoint On-Premise dat op lokale servers werd geïnstalleerd. Deze On-Premise omgevingen konden worden aangepast en gepersonaliseerd door webonderdelen te maken en te implementeren. Deze webonderdelen werden gemaakt in C# en Visual Studio werd daarvoor gebruikt. Zodra een webonderdeel klaar was, kon men de code bundelen in een wsp-bestand. Zo’n wsp-bestand is in feite een Cabinet-bestand, en dit bestand kon vervolgens worden geïmplementeerd in de SharePoint Central Admin-webapplicatie.

Bij het implementeren van zo’n wsp-oplossing werden de dll-bestanden geplaatst in de BIN-map van de GAC (General Assembly Cache).

Nadeel van deze manier van werken: Er waren over het algemeen beveiligingsbeperkingen voor code-toegang op de code die in de GAC was geïnstalleerd. Er was dus geen grondige beveiliging. Met andere woorden, de geschreven code was Full Trust-code.

Sandbox-oplossingen ~ 2010

In Microsoft SharePoint 2010 werden Sandbox-oplossingen geïntroduceerd. Dit waren applicaties die draaiden in een veilig, gecontroleerd proces met toegang tot een beperkt deel van de webfarm. Microsoft SharePoint 2010 gebruikt een combinatie van functies, oplossingsgalerijen, oplossingsmonitoring en een validatieframework om sandbox-oplossingen mogelijk te maken.

In Visual Studio kon je kiezen voor een farm-oplossing om de oplossing als farm-oplossing te implementeren, of door de eigenschap Sandboxed Solution op false in te stellen. Als gevolg hiervan werd de oplossing geïmplementeerd op de webfarm en waren deze wijzigingen van toepassing op de webfarm en alle siteverzamelingen daaronder.

Een Sandbox-oplossing had daarentegen alleen betrekking op een siteverzameling. Dit kon je bereiken door de eigenschap Sandboxed Solution op true in te stellen of door te kiezen voor het implementeren van de oplossing vanuit Visual Studio als sandbox-oplossing.

Maar waarom?

In Windows SharePoint Services 3.0 was het alleen mogelijk om oplossingen op farmniveau te implementeren. Dit betekende dat potentieel schadelijke of destabiliserende oplossingen konden worden geïmplementeerd die invloed hadden op de gehele webfarm en alle siteverzamelingen en applicaties die daaronder draaiden.

Door het gebruik van sandbox-oplossingen konden oplossingen echter worden geïmplementeerd in een deelgebied van de farm: een specifieke siteverzameling. Voor extra bescherming werd de oplossingsassembly niet geladen in het hoofd IIS-proces (w3wp.exe). In plaats daarvan werd het geladen in een afzonderlijk proces (SPUCWorkerProcess.exe), dat wordt bewaakt en quota’s en beperkingen implementeert om de farm te beschermen tegen sandbox-oplossingen die schadelijke activiteiten uitvoeren.

SharePoint add-ins ~ 2013

In 2013 bracht Microsoft SharePoint add-ins uit. Oorspronkelijk Microsoft Apps genoemd, maar later werd deze naam gewijzigd naar add-ins.

Er waren 2 typen Microsoft add-ins:

• SharePoint hosted: alle client-side zaken (HTML, CSS, JavaScript) code die was opgeslagen in SP maar werd uitgevoerd als client. Het werd aangeboden door SharePoint maar draaide niet op de server.
• Provider hosted: kon alles bevatten maar moest buiten SP draaien. De grootste uitdaging was hoe beperkt de elementen van een add-in werden gepresenteerd in SharePoint. Want elke keer dat we een add-in aan een SharePoint-site toevoegden, maakte SharePoint een child-site waar de add-in was geïnstalleerd. Hierdoor kon Microsoft de add-in isoleren van de rest van SharePoint. Vanuit beveiligingsperspectief: prima, maar alles moest via iframe worden gedaan en ze waren niet responsief, etc.

Script-injectie ~ 2013

Omdat add-ins minder dan ideaal bleken, begonnen ontwikkelaars JavaScript-injectie via Content Editor Webparts te gebruiken om de UI-ervaring aan te passen. Maar het gevaarlijke daarvan was dat er niets was om te voorkomen dat iemand pagina’s op willekeurige wijze kon bewerken. Hetzelfde gold voor SharePoint Designer, waarmee je de MasterPage kon aanpassen, en omdat een MasterPage op elke pagina in je SharePoint-farm wordt gebruikt, is dat niet bepaald veilig.

Bovendien kon je JavaScript kapotgaan als SharePoint een update uitvoerde.

SPFx 2017

In 2017 kwam Microsoft met het SharePoint Framework, dat ontwikkelaars de mogelijkheid bood om client-side aanpassingen te maken in plaats van server-side, die konden worden verpakt en geüpload naar SharePoint-sites, net zoals SharePoint-oplossingen en add-ins in eerdere versies. Bovendien hebben deze client-side aanpassingen de mogelijkheid om eenvoudig de APIs te gebruiken voor SharePoint-data die het framework biedt, maar je bent daar niet toe beperkt. Nee, je kunt elke data opvragen met de SharePoint REST API, Microsoft Graph of welke API je maar wilt. Denk bijvoorbeeld aan een Azure Function API, een API van AWS of zelfs iets heel anders zoals 4ME. 4ME is een servicebeheersysteem dat hetzelfde autorisatieprotocol gebruikt als Office 365, namelijk OAUTH 2.0, zodat je de 4ME APIs kunt gebruiken en allerlei dingen daarmee kunt doen binnen het SharePoint Framework.

Bovendien worden alle aanpassingen gemaakt binnen de huidige context. Geen verhoogde rechten meer zoals mogelijk was met server-side oplossingen, en het allerbelangrijkste: geen iframes meer. Wanneer je data wilt ophalen, hoef je niet te authenticeren omdat de code die aanroep naar de data uitvoert als de ingelogde gebruiker. Je hebt dus niet meer die zware authenticatie-autorisatielaag die een iframe nodig zou hebben.

Aanpassingen zijn responsief en toegankelijk waarbij de ontwikkelervaring de webdevelopment-stack omvat — daar komen we later op terug, maar wat dat betekent is dat je niet langer gebonden bent aan Microsoft of bijbehorende producten. Je kunt open-source tools gebruiken om SharePoint Framework-oplossingen te maken! Je hebt geen zwaar Visual Studio nodig, dat ook nog betaald is. Nee, je kunt lichtgewicht tools gebruiken die gratis zijn.

Bovendien werken SharePoint Framework-oplossingen op zowel klassieke als moderne pagina’s in SharePoint. Ten slotte zijn SharePoint Framework-oplossingen toegankelijk voor eerstelijns- en derdelijnsmedewerkers. Derdelijnsmedewerkers zijn mensen die dingen maken. Vroeger was het zo dat, zoals bij SharePoint Add-ins, deze alleen toegankelijk waren voor derdelijnsmedewerkers. We hadden een SharePoint-omgeving en alleen derdelijnsmedewerkers konden dingen toevoegen die nuttig zouden zijn binnen die SharePoint-omgeving. Eerstelijnsmedewerkers zijn Microsoft die hun functies naar SharePoint Online pusht waar we gebruik van kunnen maken, en wij, als derdelijnsmedewerkers, kunnen dan onze eigen aanpassingen toevoegen die we nuttig achten.