For your information: I am currently working on the integration of the Typesense search engine into Plone 6. The integration and functionality is a mixture of collective.solr and eea.factedsearch.
My motivation for integrating Typesense with Plone 6 is having a decent and easy to configure search alternative over Solr. Typesense itself is a single-binary installation (or via Docker), easy to configure and easy to scale. The integration into Plone is supposed to be minimal invasive.
What are the long-term goals? TTW customization of facets vs "hardcoded" search engine configuration? Right now, if I understand correctly, "custom" configuration would be possible if one would reimplement static/app.js.
As with most customizations, you would configure a template with a related app.js...or you configure your different search forms some how on the backend side and expose it through a JSON view for retrieving the configuration.
Of course, you could add filters by review_state or so at some point...I am not yet sure if this would be safe enough in order to avoid any attack vector. The focus right now is on public information. I am not sure how collective.solr handle this. The main difference is that the Typesense UI talks directly to the Typesense while search requests to Solr go through Plone...but you are right, it would be nice having this functionality...but requires some thinking first.
A more complete answer: if you have custom metadata or custom text fields that you want to index, you need a custom Typesense schema that would define all fields and aspects (same as a custom catalog.xml). A custom search view would then require a custom template and a custom configuration through an app.js. Loud thinking: most of the parameters for an app.js could be provided as data attributes within the template...so some generic or declarative approach appears reasonable and doable.
I understand. I'm interested, as this last year I have been working in a similar problem space, Volto's faceted search block and, as a separate project, the EEA Searchlib that can run separately or as a Volto block.
One design choice we've made for EEA Searchlib is that the configuration should be declarative (and can be serialized as JSON), with the hope that some day we would be able to have TTW customization. Given how complex the ElasticSearch query DSL is, that may be a long dream. Declarative configuration, in our case, translates to a "live" custom registry of components and a "static" serializable part of configuration that can reference the component registry.
It's good to see other ideas and implementations in this space.
Have you thought about using the React (or some other highlevel lib) integration? This would make it easier to define custom filters/facets/result items, etc.
The DSL of Elasticsearch is a major pain..one of the reasons why I hate ES from the bottom of my heart.
I don't care much about frontend issues. So my interest ends with HTML templates and easy to use/configure Javascript code as in this example.
Side note: Typsense is (somehow) a clone of the commercial Agolia search solution and shares in many cases their API and JS libs. In fact, my integration uses parts of the Agolia JS stuff:
There are some integrations mentioned for the most common frameworks like React (but this is out of my scope and interest...my frontend team would usually handle this for me in projects):
A first release of zopyx.typesense is now available as alpha for Plone 6.0.
Support for Plone 5.2 is coming soon (there are some unresolved issues with the JS modules).
Please check the README on Github (since PyPI does not handle/render the README in Markdown properly).
