Skip to main content

Our Sitecore Adventure - Laying the Groundwork

 To set the tone for future postings I felt it best to lay the groundwork of what got us here and where we are headed.  First, I was brought into a project in December 2019 to take over an existing Sitecore implementation for a large active community of technical professionals.  Second, the team that implemented the website was an agency that was removed from the project as it began to spiral out of control.  Third, the current team supporting the site was newer to Sitecore and was keeping the lights on to make marketing deadlines.  Not trying to throw anyone under the bus but things were not in great shape walking into this project.  And on top of that we had a major conference with a set date and it wasn't moving, so not a lot of time to make huge changes right off the bat.

So we patched up the servers, optimized SQL and IIS best we could and ran with the code base we had.  We found several surprises during the conference where assumptions were made based on the implementation teams lack of understanding of the business requirements, but the site held up as best it could.  But how do we make it better?

We Made it to Conference But What Got Us Here

Our previous implementation was based on an agencies idea of a Sitecore framework.  I will not name names here to protect the innocent, but proprietary frameworks based on someone else's framework scare me for two reasons.  (1) They are not the owners of the original framework so changes to the underlying framework can break it and (2) they don't always have the team and budgets to keep up with the underlying framework.  I am not opposed to packages and extensions but lean far away from custom frameworks by an agency unless they have a product around it, which the ones I have seen around Sitecore do not.  So our previous implementation was a custom framework written in v8.1 of Sitecore, implemented on v9.0.1 (non-production release).  For those of you following along at home, Sitecore made major technical changes between v8 and v9 so some major assumptions still ran but not as efficiently as they once did.  Too many customizations and configuration changes to make it behave how they wanted and not how Sitecore envisioned.  AND the primary architect of the framework left the agency half way through the project so his next in command was promoted to complete it.  What could possibly go wrong?

Well it did get worse.  Once that team was removed from the project the next team stepped in (Kudos to them) but were not well versed in Sitecore.  They learned quickly and did their best but they were already working with someone else's customized implementation and were under the gun to deliver on time.  Again, not trying to blame anyone here as I believe everyone had the best intentions on this project just not the best circumstances to work under.  It was not ideal conditions at all for this project.  

And as developers tend to do under pressure, they find the easy path.  Our front-end was heavy with custom JavaScript code to fix the things that were not working which only caused it be overwhelming, hard to maintain and SLOW!!!

So How Did We Fix It

We wanted to get back to basics.  Again, users don't care what fancy framework you used as long as it performs the function they want as quickly as possible.  Nobody ever says that was a cool Angular/React/Vue website, but they do comment on the performance and ease of use.  Even better yet is when they say nothing at all but get what they need.  So we decided to invest our time and effort into using our Sitecore license to its fullest and using Sitecore Experience Accelerator (SXA).  Not only that but we put this project on a full production release of Sitecore and went with 9.3 to build out this project.  I know at time of this writing that version 10 is now available but with the way we built out the platform we can easily move to v10 when we are ready.

We will cover each of these topics in more details but here was our focus on the move to 9.3:
  1. SXA
    1. How much of the core SXA functionality could we leverage to reduce our custom code?
    2. What is in SXA that we are missing?
  2. Scriban
    1. v9.3 introduced Scriban templates and allowed us to reduce our lines of code 
    2. Reduced lines of code also reduced the complexity and increased our ability to respond to the business needs
    3. Scriban templates are in the Content tree and allowed us to make changes without a deployment
  3. Data Exchange Framework
    1. How do we integrate to outside data sources to publish data on our site?
  4. Creative Exchange
    1. How do we separate the visual appearance from the layout so our creative teams can be efficient?
  5. Unicorn 
    1. How do we keep our local environments in sync with Dev/QA/Prod? 
  6. Azure DevOps
    1. How do we automate all the deployment so the technical team can write more and better code?
    2. How do we ensure coding practices are followed?
    3. Are we building secure code?
So the short answer is that we relied heavily on SXA and Scriban in v9.3.  The long answer will be provided in our other blog posts to keep these short.  

Some Quick Stats

To show you that we were able to reduce the code base I will share some quick stats with you.  We will explore the how behind these in the rest of the series.

First we reduced the number of lines of code from 110,501 of lines in our 9.0.1 implementation to just 45,342 lines of code in our 9.3 implementation.  By relying on the SXA modules for more functionality we only had to write our deviations from the framework and custom value added code.  No need to do most of the basic overhead that our last project was injecting on top of Sitecore.  We reduced the codebase by 60% and provided the solution the users were after.

This also allowed to reduce the complexity and reduce the number of files from 1,556 down to just 241.  Again we are only building the things we need.  This is an 85% reduction in the number of files and thus the complexity of the solution.

But how does that translate to the language breakdown.  You can see the number of lines per language in each of the charts below.  When I mentioned we were JavaScript heavy you can see the amount of JavaScript was 41% of the project.  And this was done without using a UI Framework.  This was not a JSS implementation.  JavaScript itself was not the problem but the implementation that was created here was difficult to maintain and did not work as expected across all browsers.



We will share more of the performance stats in later posts.

So until next time.
Labels:

Comments

Post a Comment

Popular posts from this blog

Quick Tip - Scriban Date Formatting in Sitecore

 With the Scriban syntax being new to the Sitecore platform with v9.3 there is definitely a learning curve but well worth the time investment.  So we will post short tips on things that we struggled with.  This is to share but also I will have a place to find it again when I need it. So you've created a date field in your Sitecore template and now need to format it for display purposes.  Or even better, you have styling differences depending on if the dates and years match for start and end points.  Let's show this below. First, get the date(s) in your Scriban template from the item.  In this scenario I was looping through child objects called i_child.  Using the Scriban date.parse function I can get the date value from the Sitecore field by this:     {{         this.startDate = sc_field i_child 'Event Start' | date.parse;         this.endDate = sc_field i_child 'Event End' | date.parse;     }} Now that we have the date values you can do things to check against
Post a Comment
Read more

Sitecore Scriban Templates – Custom Functions to the Recue

 So you jumped in head first into Scriban Templates with Sitecore.  And now you hit a wall because it doesn't do that one thing you could easily have completed in MVC forms with a controller.  Well, this is where you can build your own custom functions to work within Scriban templates.  Sitecore already provides a few of these at  https://doc.sitecore.com/developers/sxa/93/sitecore-experience-accelerator/en/the-embedded-functions-for-the-scriban-template.html . So How Do You Build Your Own? Well let's begin by discussing what we want to build.  In our project we have a need to get the nearest parent of a certain template type.  This way we can determine if the page you are viewing is part of a conference section or not.   So first, let's build the C# code that will execute when we call the function.  We decided to add a new member to the i_item to determine if we were in a conference context and allow us to call other properties as we would need. public class GetConferenceC
Post a Comment
Read more

Sitecore 9.3 – Scriban Templates – Yes Please!

 This feature sold us on our migration to Sitecore v9.3 and using SXA.  Why was it so important in our decision?  Based purely on speed to implement.  Let's explain, but first what is Scriban? What is a Scriban Template in Sitecore? Scriban is a fast, powerful, safe and lightweight scripting language and engine for .NET, which was primarily developed for text templating with a compatibility mode for parsing liquid templates. And Sitecore SXA has has adopted this new templating system whole-heartedly.  It allows a lot of your custom HTML and MVC controls to brought into the content tree.  Why is this important?  Because now you don't have to create a custom controller and CSHTML to create a rendering.  You can create and use a Scriban template. For more information refer to the documentation found at  https://doc.sitecore.com/developers/sxa/93/sitecore-experience-accelerator/en/scriban-templates.html .  You can also find more documentation on the Scriban template itself at  htt
Post a Comment
Read more