When we started out, we were short on time and thought of using either whichever covers most of our target user base. Zopfli works everywhere whereas Brotli is not supported everywhere. Also, Nginx does not support Brotli out of the box and had to be compiled. Since there were some complexities as well, we went ahead with Zopfli only.
Now that we have more time, we have the luxury to setup infrastructure for serving both Zopfli and Brotli. Perhaps one of the next steps for us to make our website even faster.
Yes it would have. But as I said in one of the other comments, they are doing something about this in 2.x releases. And this reference is from 2.x release's documentation.
Wish we had it back then. We are currently on 1.4.
I might be missing something. But to my understanding I think it is correct. I didn't quite get what you exactly mean by that? Educate me please.
To explain myself, I meant that tests that were succeeding previously would have failed due to this issue if we had tests written for it. Does my statement not convey this?
> But lack of automated regression testing would have caught this issue.
Your question:
> To explain myself, I meant that tests that were succeeding previously would have failed due to this issue if we had tests written for it. Does my statement not convey this?
No. The sentence says that the lack (i.e. not having) tests would have caught the issue. If you remove 'But lack of', the sentence makes sense ;)
Not completely sure about this. But may be we are just not in the same circles of other fields where things like these are shared. I can only speak for myself obviously. But it would be hard to believe that people in the field of medical sciences don't practice this.
Something I wondered too. But I think in the 2.x versions, they are already planning something around it. Honestly, I have not looked at it much yet but even creating another mapping with the same field name but different type should perhaps throw a warning or not be allowed unless overridden as they lead to things like these.
In 2.x, all fields must adhere to the same data type or you will get a failure [1]. To quote:
Fields with the same name, in the same index, in different types,
must have the same mapping
So hopefully this isn't an issue anymore! I do strongly suggest (and we've done this from the beginning) that no one rely on elasticsearch's auto mapping and that you should explicitly map your fields.
Yes you are right. In fact, a simple work around, before Elasticsearch coming out with this feature in their 2.x releases, was to review mappings and what goes in Elasticsearch. And we got careless about that and shot ourselves in the foot. We learned it the hard way.
