Keep your Sitecore processors small and their responsibilities smaller
A quick blogpost and a tip I have for developing Sitecore pipelines and processors.
Sitecore <3 Pipelines
Sitecore loves using pipelines and for good reason. Install a clean Sitecore solution and you’ll get a whole bunch of them. Installing a module? Boom! Get ready for a bunch more.
So, what are pipelines?
I assume every Sitecore dev out there knows about pipelines (you should). But just in case, here’s my take:
“Pipelines are just like methods, you put something in and you get something out. The difference is that with pipelines you split the body of the method into different processors.”
I think it’s a great technique they use and allows you to change OOTB Sitecore behavior. You can add your own processors, replace existing ones or just shuffle around a bit. No need to hack the source code, all you need to do is patch the configuration and have it your way.
Keep processors small and descriptive
Installing the Commerce Connect module means you get a bunch of extra pipelines (among other things). The ‘commerce.carts.createCart’ pipeline for instance. Equipped with 3 processors that Sitecore delivered and we added a custom ‘Solution.CreateCart’ processor.
The custom CreateCart processor would go to the external commerce system and request a new cart. All fair and simple, but when looking at the code I saw that processor had 100s of lines and was doing a lot more than just requesting a new cart.
I had to put in quite some effort to reverse engineer and find out what’s was going on. And as I was clustering code by the purpose it served, I had a bit of an epiphany:
“Processors should be kept small and have a single responsibility”
Doing that allowed us to use descriptive names for the processors and putting it to practice gave us some advantages that I find very useful:
- Documentation in code/configuration
It removed the need for me to put my reverse engineering notes into official documentation. You could tell what was going on where and when just by looking at the configuration. - Re-use across pipelines
By modifying a few processors we could re-use some of them across pipelines. - Easier to create unit tests
It was easier for us to create unit tests because the smaller the unit, the easier it gets. - Utilize the Pipeline Profiler
The pipeline profiler was telling us precisely where bottlenecks were created. - Easier to maintain and modify
It was easier for us to compose the methods and change specific parts without having to go through 100s of lines of code
And that’s basically my tip: Get to know pipelines. Keep your processors small and their responsibilities smaller. Use descriptive names.