Disable the reverse proxy

Warning
Legacy feature

This article pertains to the Coveo Hive framework which is now in maintenance mode.

Choose one of Coveo’s more modern, lightweight, and responsive libraries for any future search interface development. See the search interface Implementation guide for more details.

As of the October 30, 2020 release, you can disable the Coveo for Sitecore reverse proxy through the Command Center.

Enabling proxy setting in Command Center | Coveo for Sitecore 5

When you disable the Coveo for Sitecore reverse proxy, your Coveo Hive interface search and usage analytics requests are performed directly against Coveo Platform endpoints.

Important

Coveo Hive search interfaces now perform front-end calls through the REST endpoint proxy to generate search tokens, even when you disable the proxy. Caching /coveo/rest endpoint responses may cause issues.

Animation showing search request relaying with proxy | Coveo for Sitecore 5
Search request handling and processing with Coveo for Sitecore reverse proxy enabled

  1. Coveo Hive search page sends search request to Coveo for Sitecore proxy endpoint.
  2. Coveo for Sitecore query processing pipeline processors modify request payload.
  3. Coveo for Sitecore proxy relays modified search request to Coveo search endpoint.
  4. Coveo sends response back to proxy endpoint.
  5. Coveo for Sitecore response processing pipeline processors modify JSON response.
  6. Coveo for Sitecore proxy relays modified response to search page.
Image showing search request path without proxy | Coveo for Sitecore 5
Search request and response with Coveo for Sitecore reverse proxy disabled

  1. Coveo Hive search page sends search request directly to Coveo search endpoint.
  2. Coveo sends response back to search page.

Pros and cons of disabling the reverse proxy

Choosing between using or disabling the Coveo for Sitecore reverse proxy is a matter of context.

Examples
  • A Coveo for Commerce customer using Sitecore on Azure should bypass the proxy to increase perceived search performance and to reduce Azure usage costs. Moreover, the Coveo for Commerce customer draws no advantage from Coveo for Sitecore search pipelines designed to handle responses containing Coveo for Sitecore source data (see Compatibility with Sitecore Commerce).

  • A customer with a scaled on-premises Sitecore XM or XP environment would benefit from enabling the reverse proxy, especially if they’re inclined to leverage Coveo for Sitecore search pipelines for custom code.

In more detail, consider the advantages and drawbacks in the table below when deciding whether to disable the Coveo for Sitecore reverse proxy.

Criterion Using the proxy Bypassing the proxy

Host resolving

plus

Out of the box, a Coveo for Sitecore response processing proxy pipeline runs the ResolveResultClickableUriProcessor processor and resolves your item clickable URIs in the context of the current site.

minus

In a scaled Sitecore environment, you’ll need to account for the fact your clickable URIs are not automatically recomputed at query time (for example, by ensuring your items are indexed with content delivery (CD) site URIs).

Search query durations

minus

Search query requests and responses are relayed by the proxy. Server thread handling, proxy pipeline operations (for example, deserialization and reserialization of search request payloads), and processor execution increase overhead.

plus

Your search requests are sent directly from your search interface to the Coveo search endpoint, resulting in shorter query durations.

Custom processing of search queries/results

plus

Coveo for Sitecore provides pipelines to alter search queries before they’re sent to Coveo, and to handle and modify the Coveo responses. You can run your custom processors in these pipelines, leveraging Sitecore context (see About the REST endpoint pipelines).

minus

You’ll need to consider using query pipeline features to alter search requests in Coveo before they’re sent to the index. Though query pipeline features are powerful, only the trigger feature lets you alter the query response, but not the search results themselves.

Load on server

minus

Using the proxy produces two hits on your server for each search and usage analytics request, increasing the load on your server.

plus

Your server is hit only once for each search and usage analytics request. On hosted platforms (for example, Azure), where usage costs may depend on the number of hits to your backend, bypassing the proxy can translate into cost reductions.