OVERVIEW

FOR EPISERVER DATA REPOSITORY 

To store data fetched from API. We decided to use EPiServer’s own caching mechanism that was based on HTTPCache. When pulling data from the External API (for booking information) and caching it, we ran into an issue with the way EPiServer DXC is setup where cache is not synchronized across multiple server instances within one DXC. The ISynchronizedObjectInstanceCache only synchronizes deletions. To solve this issue, we created a new module called “DDSCache”. This was essentially a cache that was backed by DDS (Dynamic Data Store). The idea was that everything is loaded into HTTPCache, but If it needs to do a cold reload, then instead of having to make the API calls, it will use the database instead. 

FOR CODE SEGREGATION 

With multiple DXC and different audience types and feature sets, we wanted the feature set available to each one to be configurable without having to clone the code across those DXCs. We decided to create multiple NuGet packages that were self-contained. The only dependency was the Core package that had all the interface definitions. If any add on needed to support site settings, it just declared it as a dependency and processed to use it in the standard Dependency Injection pattern. The dependent add on itself was responsible for managing the admin UI etc. for that feature. So, when we went from DXC to DXC, we were able to install the libraries needed for each on (for example, which booking engines were supported) and they were auto registered. 

FOR CONFIGURATION 

By default, Episerver keeps “site settings” as a tab on the home page for content editors. This causes a couple of issues when managing permissions. We went out and created a brand-new service called the ISiteSettingsService. This service was backed by DDS and had a whole separate admin panel in EPiServer that could be controlled on its own with granular permissions (Permissions for Functions). Using this service, any external addon could inject its own definition of what it needed the content editor to specify at a site level and could be made completely plug and play. The same concept was extended to both the style manager as well as global settings.

 Technology stack used to achieve the results : 

• EPiServer CMS / ASP.NET MVC 5
• Frontend – jQuery + AngularJS
• Datastore – Azure SQL
• Content Data Storage – Azure Blob
• CDN – Cloudflare
• Cache Synchronization – Azure Event Hub