We all know that SharePoint has a bit of a reputation in the industry. On one hand, it is an indubitably powerful and flexible system that has a lot of success stories to tell, especially in the intranet context. On the other hand, it is also known as a complex tool that has been often abused, leading to slow and ugly implementations that fell just short of the mark in terms of usability, performance, and functionality.
In this article, we tell the story of our recent successful case with SharePoint as a headless CMS, and how it fixes a lot of traditional issues while ushering a new era of beautiful websites with a great backend powered by SharePoint. Of course, before we started this case, we pre-discussed our approach with Microsoft to make sure it aligned with their SharePoint strategy.
First things first – how does a traditional CMS work?
Consider a CMS such as Drupal, WordPress, Sitecore or SharePoint. The usual functionality we can find is roughly divided in two big buckets: the content management functionality itself, and the templating/presentation capabilities. Traditionally, one would use a CMS for editing pages (content management proper), but then of course this content would need to be presented somewhere. In the olden days (actually, in many cases still today!) one would (we wouldn’t) let the CMS also take care of the presentation of the content in some nice format as a web page. This is where the issues would start!
What should a CMS do?
Content management is a pretty standard toolbox. We need to be able to define content types, often also in relationship to each other (sometimes referred to as a taxonomy). We need editors, with proper roles and rights. We need some workflow for content auditing. We often need multi-language support. And that’s roughly it (admittedly very roughly, but for the purpose of this article let’s keep it at this). A standard toolbox can be built once and reused. And this is where SharePoint, especially with the modern editor, integration with Office 365, and a huge enterprise-level feature set, easily dominates its competition.
Presentation of content, branding and CX
Content presentation is far less standard. One might argue that there is nothing standard at all about a company’s identity, branding, and emotional relationship with its customers through online channels. One website might feature engaging animations and bright colors, whereas another might convey a serious corporate mindset, while a third website could try to translate the atmosphere of a restaurant chain, a hospital, and so on. Trying to build a rendering system that somehow captures all of these aspects in one easy go is, mildly put, very difficult. I personally believe it to be outright impossible. Conveying something as subtle and complex as a visual identity requires the masterful work of professional designers, and the most capable and flexible technical tools and frameworks available on the market. It does not matter how fancy a CMS is, its rendering system will never be fully at the level of modern web development frameworks such as React and Angular.
With Microsoft’s Graph API, we can have our SharePoint for content management and have a separate, hand-crafted Single Page Application built in React and TypeScript show this content in a fast, beautiful and responsive way.
A layered architecture – headless CMS
In order to be able to enjoy the benefits of both the great CMS and back-office capabilities of SharePoint, while not being encumbered by its rendering system, we can use SharePoint as a headless CMS.
SharePoint, in both the Online and On Premise variants, supports the publication of its content via Microsoft’s Graph API (based on the OData protocol). This means that we could have our SharePoint, use it to produce and manage content, and then have a separate, hand-crafted Single Page Application built in React and TypeScript show this content in the fastest, most beautiful, most engaging, responsive way. Our designers have total freedom to design what the website really needs to be, and developers have no silly constraints because React and TypeScript can be used to achieve anything we might ever want to build (even a 3D AR/VR website, if we want!).
Data and system integration
The connection between the React frontend and the SharePoint backend is supported by a C#/.NET Core integration layer. This integration layer offers a series of important advantages. For example, we could build a cache in order to weigh less on the underlying SharePoint CMS, while speeding up the frontend of the website by a significant factor. Integrations with other systems such as a Business Central ERP/CRM, SalesForce, Navision, SAP, or more would be built in the integration layer, instead of in the CMS itself, thereby keeping the CMS simple and streamlined and having the business and data integration logic in a place where it makes more sense.
Of course, this is in addition to all the fantastic integrations that SharePoint already supports in a Microsoft-oriented organisation, ranging from the Power Platform, Office 365, Microsoft Teams, and more. For an organisation already using Office 365 and other Microsoft solutions, adding a SharePoint CMS to a multichannel, uniformly branded customer experience in line with the expectations for top of the line organisation, is finally a reality!
Time to enjoy the benefits
Thanks to a headless approach to SharePoint, coupled with a layered architecture, it is finally the time to enjoy the benefits of one of the most powerful, battle-tested CMS systems in the (enterprise) world. While at the same time creating fast, beautiful, engaging frontend user experiences in a modern framework such as React.
Find me at firstname.lastname@example.org if you want to know more about the benefits of SharePoint as part of a headless architecture!
Schrijf je in voor onze nieuwsbrief en laat ons jouw gids zijn in een complexe digitale wereld.