MichaelXavier
commented
4 years ago I personally am not really interested in that approach. Bloodhound does have a lot of effort behind it to track the extremely unstable and shifting APIs of Elasticsearch. We're able to offload that ongoing effort by depending on bloodhound itself. If you haven't checked recently you may want to look at the git version of Bloodhound. GHC compile times get really bad on large modules and some time ago Bloodhound has a massive types module. It has now been broken up into some smaller modules specifically to speed up compile time and help with code organization.
However, katip is designed to allow custom scribes. What I would support is you creating and maintaining a library, say katip-elasticsearch-lite that shed the bloodhound dependency. I would happily link to that repo in katip. I would also support efforts to either create a utility package or exporting from katip itself some combinators that katip-elasticsearch uses to manage worker threads and maintain queues of messages, send them in batches, etc. These are generally applicable patterns and IIRC don't carry too many dependency burdens, so maybe katip could provide those as a head start for any 3rd party scribes.
Bloodhound is great when an application heavily depends on elasticsearch, especially for the search aspect, but there is a cost:
(1) Building Bloodhound is really slow (I'm not sure I ever understood why) (2) It's a slow moving project whos dependencies dont update very often
Right now I'm unable to upgrade to a recent LTS in a larger project because of bloodhound deps, and on a brief investigation tells me that this library is not really using it in any complicated way (just for index management and posting documents). Would you be willing to replace bloodhound with a little tiny client library? I would volunteer to post an outline and do the work, since I have already had to do this in another project for similar reasons.