Story

We should implement tests to measure how well smartsearch components are scaling with a growing number of documents.

Story

One of lasts commits have introduced a nice feature that applies gzip compression on the fly to returned lists of documents.

This have drastically improved performances on many browsers like Chrome or Safari but broken our demo application with Explorer or Edge.

Looks like Explorer and Edge are simply not decompressing the data, they try to parse them as a stream of JSON directly. Of course they fail.

Solution

A possible, and elegant solution, can be to let the client choice to have the documents compressed or not.

Let's imagine to revert method /docs as it was before and to add another identical method /docs.gz that is obtained by decorating the first with a gzip encoding.

On the client side we can test the current browser's capabilities and decide what method use.

This would also make us easier to test and to compare time to time the 2 different solutions. For example have no sense to use compression if we have only few documents to return.