Série SPFx : L'histoire du développement SharePoint

Bienvenue dans la Série SPFx ! Dans cette série de blogs, nous allons plonger en profondeur dans le SharePoint Framework (SPFx), un puissant ensemble d’outils pour créer des solutions modernes et dynamiques dans SharePoint et Microsoft 365. Dans cet article de blog, nous allons explorer l’histoire du développement SharePoint.

Les WebParts en tant que solutions de ferme ~ 2007

Par le passé, il n’existait que SharePoint On-Premise ; la question d’un environnement cloud ne se posait pas, car la première introduction de SharePoint Online remonte à 2012. Il n’y avait que SharePoint On-Premise, installé sur des serveurs locaux. Ces environnements On-Premise pouvaient être personnalisés en créant et en déployant des WebParts. Ces WebParts étaient créés en C# et Visual Studio était utilisé à cet effet. Une fois un WebPart prêt, on pouvait regrouper le code dans un fichier wsp — un tel fichier wsp est en fait un fichier Cabinet — puis déployer ce fichier dans l’application web SharePoint Central Admin.

Lors du déploiement d’une telle solution wsp, les fichiers dll étaient placés dans le dossier BIN du GAC (General Assembly Cache).

Inconvénient de cette façon de travailler : il y avait généralement des restrictions de sécurité d’accès au code installé dans le GAC. Par conséquent, il n’y avait pas de sécurité approfondie. En d’autres termes, le code écrit était un code Full Trust.

Solutions sandbox ~ 2010

Dans Microsoft SharePoint 2010, des solutions sandbox ont été créées. Il s’agissait d’applications qui s’exécutaient dans un processus sécurisé et contrôlé ayant accès à une partie limitée de la batterie de serveurs web. Microsoft SharePoint 2010 utilise une combinaison de fonctionnalités, de galeries de solutions, de surveillance des solutions et d’un cadre de validation pour activer les solutions sandbox.

Dans Visual Studio, vous pouviez choisir une solution de ferme pour déployer la solution en tant que solution de ferme, ou en définissant la propriété Sandboxed Solution sur false. En conséquence, la solution était déployée sur la batterie de serveurs web et ces modifications s’appliquaient à la batterie de serveurs web et à toutes les collections de sites qui en dépendaient.

En revanche, une solution sandbox ne concernait qu’une seule collection de sites. Vous pouviez y parvenir en définissant la propriété Sandboxed Solution sur true ou en choisissant de déployer la solution depuis Visual Studio en tant que solution sandbox.

Mais pourquoi ?

Dans Windows SharePoint Services 3.0, il n’était possible de déployer des solutions qu’au niveau de la ferme. Cela signifiait que des solutions potentiellement nuisibles ou déstabilisantes pouvaient être déployées et avoir un impact sur l’ensemble de la batterie de serveurs web et sur toutes les collections de sites et applications qui y étaient exécutées.

Cependant, en utilisant des solutions sandbox, les solutions pouvaient être déployées dans une sous-zone de la ferme : une collection de sites spécifique. Pour offrir une protection supplémentaire, l’assembly de la solution n’était pas chargé dans le processus IIS principal (w3wp.exe). Au lieu de cela, il était chargé dans un processus séparé (SPUCWorkerProcess.exe), qui est surveillé et met en œuvre des quotas et des restrictions pour protéger la ferme contre les solutions sandbox effectuant des activités malveillantes.

SharePoint Add-ins ~ 2013

En 2013, Microsoft a publié les SharePoint Add-ins. Initialement appelés Microsoft Apps, Microsoft a ensuite changé ce nom en add-ins.

Il existait 2 types de Microsoft add-ins :

• Hébergé par SharePoint : tout le code côté client (HTML, CSS, JavaScript) était stocké dans SP mais était exécuté côté client. Il était servi par SharePoint mais ne s’exécutait pas sur le serveur.
• Hébergé par le fournisseur : pouvait tout contenir, mais devait s’exécuter en dehors de SP. Le plus grand défi était la manière très limitée dont les éléments d’un add-in étaient présentés dans SharePoint. Car à chaque fois qu’on ajoutait un add-in à un site SharePoint, SharePoint créait un sous-site où le add-in était installé. Cela permettait à Microsoft d’isoler le add-in du reste de SharePoint. Sur le plan de la sécurité : parfait, mais tout devait passer par des iframes, ils n’étaient pas adaptatifs, etc.

Injection de scripts ~ 2013

Puisque les add-ins s’avéraient moins qu’idéaux, les développeurs ont commencé à utiliser l’injection JavaScript via des WebParts Éditeur de contenu pour personnaliser l’expérience utilisateur. Mais le danger de cette approche résidait dans le fait qu’il n’y avait rien pour empêcher quiconque de modifier les pages de quelque manière que ce soit. Il en allait de même avec SharePoint Designer, où vous pouviez personnaliser la MasterPage, et puisqu’une MasterPage est utilisée sur chaque page de votre ferme SharePoint, ce n’était pas exactement sécurisé.

De plus, votre JavaScript pouvait être cassé lorsque SharePoint effectuait une mise à jour.

SPFx 2017

En 2017, Microsoft a introduit le SharePoint Framework, qui offrait aux développeurs la possibilité de créer des personnalisations côté client plutôt que côté serveur, pouvant être packagées et chargées sur des sites SharePoint, tout comme le faisaient les solutions et add-ins SharePoint dans les versions précédentes. De plus, ces personnalisations côté client ont la capacité d’utiliser facilement les API pour accéder aux données SharePoint que le framework propose, mais vous n’êtes pas limité à cela. Non, vous pouvez interroger n’importe quelle donnée avec l’API REST SharePoint, Microsoft Graph ou n’importe quelle API de votre choix. Par exemple, une API Azure Function, une API d’AWS ou même quelque chose de complètement différent comme 4ME. 4ME est un système de gestion des services qui utilise le même protocole d’autorisation qu’Office 365, à savoir OAUTH 2.0, vous pourriez donc utiliser les API 4ME et faire toutes sortes de choses avec elles dans le cadre du SharePoint Framework.

De plus, tous les ajustements sont effectués dans le contexte actuel. Plus de privilèges élevés comme c’était possible avec les solutions côté serveur et, surtout, plus d’iframes. Lorsque vous souhaitez appeler des données, vous n’avez pas besoin de vous authentifier car le code exécutera cet appel aux données en tant qu’utilisateur connecté. Vous n’avez donc plus cette lourde charge de la couche d’authentification et d’autorisation dont un iframe aurait besoin.

Les personnalisations sont adaptatives et accessibles, et l’expérience de développement inclut la pile de développement web — nous y reviendrons plus tard — mais ce que cela signifie, c’est que vous n’êtes plus lié à Microsoft ou aux produits associés. Vous pouvez parfaitement utiliser des outils open source pour créer des solutions SharePoint Framework ! Vous n’avez pas besoin d’un lourd Visual Studio, qui est également payant. Non, vous pouvez utiliser des outils légers qui sont gratuits.

De plus, les solutions SharePoint Framework fonctionnent à la fois sur les pages classiques et modernes dans SharePoint. Enfin, les solutions SharePoint Framework sont accessibles aux personnes de première ligne et de troisième ligne. Les personnes de troisième ligne sont celles qui créent des choses. Autrefois, comme avec les SharePoint Add-ins, par exemple, celles-ci n’étaient accessibles qu’aux personnes de troisième ligne. Nous avions un environnement SharePoint et seules les personnes de troisième ligne pouvaient ajouter des éléments utiles dans cet environnement SharePoint. Les personnes de première ligne sont Microsoft qui déploie ses fonctionnalités dans SharePoint Online dont nous pouvons profiter, et nous, en tant que personnes de troisième ligne, pouvons ensuite ajouter nos propres personnalisations que nous pensons être utiles.