A Battle – Coveo Search Framework | Coveo Search API

I am going to give it away to you all in who is the winner. 🙂

In reality, I think there is no battle when there is a clear winner and your vision to pursue should always be to use Coveo for Sitecore platform.  When the world turns up side down, you hit the wall like 100 times and when Coveo team also gives up only then you would pick the other option to build ground up.

Folks who love to code to solve problems or passionate to take full control in to their own hands in terms of business logic implementation have to remember and think about why did the executives spent money and time investing in Coveo For Sitecore.  Now, with the cloud version, their biggest selling point is of no suspense, heavy contexual marketing and machine learning are sure a huge cherry on top to their easy to integrate search experience.  Between, if you have installed Coveo for Sitecore on-premise and then also had experience with Coveo For Sitecore cloud, you will have to agree with me.  It took minute slice of earlier to set up cloud platform on a Sitecore instance.

Recently, after we did a thorough comparison between these two options for one of our clients, Coveo team released their best practices, I included the link here.  If you have not already, please check this out, it is very useful.  I definitely learned and shared a thing or two from here with my teams.  Now, this document just solidified what we pitched and I could not be more happier. I mean getting a backing from Technical Architects from Coveo on what we thought was correct approach.  Nice feeling you all!

Coveo Best Practices Document:  https://developers.coveo.com/display/public/SitecoreV4/Coveo+for+Sitecore+Project+Guide

Hint:  Look at Page Number 52 – Section Developing Against the Coveo Search API directly

I would like to share pros/cons of these approaches for any one who is trying to convince their client to not lean towards re-building something they don’t have to. 🙂

To keep this to the point, I will list what you will miss if you go with using Coveo Search API instead of Coveo for Sitecore framework.

Disclaimer:  Got to Hurt…Ouch!!!

  1. You will forgo ability to be able to add in Coveo Custom Components, they are becoming more and more powerful especially if you have Enterprise and above license where you hardly would need to write any JS, just use properties as much as you can to pass in those Filtering and other settings.
  2. Incremental refresh of Indexes – Depending on how huge your solution is, this will hurt you more. 😉 Coveo when integrated with your sitecore deeply you will notice that it taps on to most important pipelines to ensure it keeps your master and web indexes in sync using some clever strategies.  That means it will not rebuild the whole indexes until you request it to do so, saving lot of time and being efficient.  Web sources and other type of indexes you might create might not have this feature.
  3. Machine Learning/Coveo Analytics and any thing beyond.  Now, let me re-iterate the obvious, the world is moving towards AI for better or for worse and this might be one the biggest reasons why Coveo was a big win and hence the decision to go forward with the product.  Coveo Analytics are collected through one of their component that when added to search interface will push all the goodness ML would need to then use awesome Coveo ML features such as query suggestions and ART for instance.  You will miss out on this if you do not install the framework.  Now, I do see some API’s with which you can get usage analytics and either do a read or write to Coveo Analytics using the same, but, why go through this process when you can simply add a component that has been built and tested by Coveo.  If you are curious –



There could be more?  you think you know some? Leave a comment.

Now, remember all this losses while making a decision, but, also do understand that in some really complicated architectures where there seem to be no way that we can seamlessly integrate and use full power of Coveo platform then Coveo Search API in combination of a lot of custom code might be a way.  But, before you go that route I urge you talk to every one you think might know a different, better or easier way to fully juice and extract the goodness of the platform.  At the end of the project, we definitely do not want regret on our plate on this type of decisions.

Now go out there and make some tough decisions. 🙂

Sitecore Image Optimization

Optimize Images

Time and time again you see yourself solving an issue or providing a solution to a problem that seem to exist regardless of breadth of solution.  One such problem I noted on my clients is Images, no matter how advanced the actual sitecore implementation is, for some reason Images and their handling are not taken seriously enough.

On the projects where I am leading the technical effort, I almost always ensure and push the team to think about this because when we launch the site, it is sure very important to get the functionality right, but, what is also important is to ensure tools like Google page speeds and others out there give your effort a good ranking.  You might say, well it is just a number, but, it is important to understand the number is mere representation how fast and efficient your solution is and hence the numbers and issues are important.  At the end of the day, you want to see your website where you put in so much effort and money lands well on Google. 🙂

I am a true believer that we should never be re-inventing the wheel and always see where we can get with couple of smart solutions out there that folks use for this very purpose.  I toyed around with couple of options and compared them on different aspects, so, we can make a decision on next steps to get us where we would like to be.

Below are my findings on this comparison.

Note:  I am not supportive of either of these options I researched and only providing my thoughts around it.  Not meaning to offend any one or praise any one either.  🙂

Please leave a comment if you have any more thoughts or options that could prove to be useful.

Tools investigated are:

Dianoga – https://github.com/kamsar/Dianoga/blob/master/README.md

Image Crunch – https://github.com/1508/SitecoreExtension.ImageCrunch

Comparision Sheet between the favorites

 DianogaKraken Based API calls
Installation and Set upWorks OOTB, no need to tailor or modify unless very specific needs arise
If CDN is in play, additional configuration might be needed. See some more steps noted for CDN set up here:
We will need to test with CDN in play to ensure it still works with this additional steps
• Would need some honing as module does not seem to be perfect and need some issues to be addressed. See Git hub notes by me to the author –
• API keys based on subscription for Kraken
Custom CodeNot needed for optimization specificallyWill be needed more than likely to ensure we tailor the solution to our needs. Can take reference from the module suggested and make it our own.
SubscriptionFreeMonthly subscription needed
Google Page SpeedStill few images not compressed to what Google expects it to be at.
But, I came to know that Dianoga works it's best with scaling parameters, so check that out if your implementation does not have scaling in place.
Compression respected by Google algorithm
Served FromMedia Cache
Image should be available on media cache which is based on request to the resource, so, optimization is on-demand
Media Library
Hook is on media library, so, every time a new image is uploaded or attached Kraken is called to Optimize the same if needed.
For existing images, there are few calls we can make right from content author ribbon.
Publish would be needed to ensure optimized images are being served upon request
Cache should be cleared if not already in play on CDN to ensure newly optimized images will be served

That is it you guys, hopefully this helps some one looking for a solution to optimize their Sitecore imagery.  Both of these options are unique in terms of how they deal with the problem on hand.  Ultimately, both seem to be good, so, picking an option would be mainly based on business and development teams preference based on their implementation.