Episerver solution best practices

Recently I came across great blogs regarding Episerver coding best practices from Adnan Zameer, Khurram Khan & Stefan Holm Olsen. They pretty much covered all code related pain points. I thought I should give my input related to Solution design & software architecture point of view (especially for eCommerce projects – eCommerce projects are more close to my heart.)

Custom Tables

In general, don’t add/use custom tables in the CMS or Commerce databases. If you have to use it (There are valid scenarios) then don’t store customer’s transactional information in these custom tables.

Custom tables do not give you the cache layer that the Episerver data access layer provides and if you have a problem in the production environment it is really hard to investigate. Especially if your website is hosted in DXP.

By creating custom tables you probably able to save some money but in the longer run, it’s really expensive to maintain.

Integrations

Nowadays almost every eCommerce solution needs to integrate with different back office or 3rd party solutions. Essentially it’s not hard to integrate with a 3rd party service or a back-office solution, the real challenge is, how you integrate.

  • Your integration should be scalable. Episerver WebApps are scaleable but if your website is dependent on an integration endpoint that is not scaleable, the effects will be counterproductive.
  • If the integration endpoint is not responding in milliseconds then it’s not web-ready. Use service bus or service Gateway products.
  • Integration points should have proper authentication/authorization

Dynamic data store

DDS is not just another storage solution. It’s expensive to retrieve results from DDS. In my opinion, if your query to DDS is going to retrieve more than one result set then reconsider using DDS.

Geta created a really useful tool to explore DDS (Not sure if they still maintain it.)

Cache

I think a lot of bloggers had already written when to use cache and what type of cache technique to use. However, I’ll discuss what cache tool you can use.

In my point of view, if you are storing list objects in cache or you have distributed architecture & some integrations are not web-ready then use Radius cache instead of in-memory cache. You can warm-up your cache through a microservice and later website can utilize it.

Queuing (Virtual Waiting Room)

During high traffic times its very common for eCommerce websites to start a virtual queue of customers and release controlled traffic to the website.

Now implementing queue is not very difficult using tools like queue-it etc. The important bit is to understand how your website behaves in high concurrent customer traffic, what is your normal and peak thresholds.

Where you implement queue? Such as your home page or anything beyond the basket page etc. Normally it is not advised to use cache on basket & checkout pages, so these pages hit hard with the high volume of traffic.

Customers in Commerce Manager

If the website has a large customer base and internal users need to use commerce manager to review or update customer’s information then you should SSO solutions like Azure B2C or similar.

Commerce manager views are not meant to handle such pressure. The problems related to filters/sort in Contacts or other views are not only become a problem but it can take your website down. (i learn it the hard way)

DOM manipulation

Every project has different requirements but in general, I avoid to implement anything that directly manipulates DOM. It will create problems with personalization through visitor groups.

It could be a javascript code, a code added through google tag manager or if you are using a different content personalization provider.

Web Jobs

Web jobs are an exciting feature from Azure. Episerver supports the Continous WebJob type.

While working with WebJobs, your connection with the database should be a singleton. Another option is to use the Singleton attribute. Otherwise, you will end up with a new instance of SqlClient with each WebApp instance.

Multi-Language

Its totally personal preference but I think if you are managing multiple languages you should write a localization provider to manage language strings in cms. It makes life a lot easier for editors and developers.

Promotions

Promotions are a very powerful feature of any eCommerce website. Episerver gives a lot of flexibility to use out-of-the-box promotions or create custom promotions. Always remember to delete expired promotions (or a better option is to write a scheduled job to delete expired promotions). Otherwise “Discount Priorities and Exclusions” become very hard to use.

Application Insight Alerts

Different websites use different monitoring tools to monitor availability and performance. But do always configure App insight alerts. It’s available for free (to All azure implementations). Alerts can inform you even about one faulty instance among 20-30 active instances. In eCommerce websites, the availability of every instance is very important.

Nested Blocks (Including Containers)

Almost everyone suggested, avoid overusing nested blocks. The whole concept is easy to understand by developers but from the editor’s point of view, it seems unnecessary. Paul Gruffydd has written a really good article “Customizing rendering to reduce nested blocks” as an alternate.

Personally, I don’t like using container blocks unless the editor wants to bundle a couple of blocks to apply one visitor group criteria.

About the author

Naveed Ul-Haq

I am a UK based technical architect. I love working with .NET based CMS, eCommerce solutions, .NET Core, DevOps, and Cloud computing. I am a Certified Episerver CMS developer, MCSD (Microsoft Certified Solution Developer) and MCP in Azure application development. I spend my free time with my family and reading books. You can contact me on [email protected]

View all posts

Leave a Reply

Your email address will not be published. Required fields are marked *