(Solr) Search in Drupal 8

On Tuesday, 24th of September we had a birds-of-a-feather session about Solr in Drupal 8 and there was an attendance of around 8-10 people. Also all the module maintainers were present in this meeting so it was perfect to have a productive meeting, which it also was.

We discussed the following topics

Changes in Drupal 8 core to the search module in core.
Possibilities to have a generic connector for Solr.
Query Class
Document Class
Indexing logic
Schema files
Views query plugin
Indexing logic and why queue is not a good option for indexing items to your search
What else we could leverage from Drupal 8

Changes in Drupal 8 core to the search module in core.

Core search was converted to use the new plugin architecture
When a filter is chosen, it adds the f query argument so that we can make facetapi compatible with core search without any weird customization.

Possibilities to have a generic connector for Solr.

This was the most discussed topic and plenty of voices wanted to see a combined module (Search API + Apachesolr) or at least understand why those two solutions are “duplicating” effort. For some parts of the modules it makes perfect sense already to combine efforts.
We agreed on the following common parts and also agreed these common parts should be placed in the Apachesolr module so that Search API can use this connector while the Apache Solr UI also uses the exact same connector.

The connector would contain :
Schema and any other configuration file required to run Solr
This is easy to do as we are already using the same schemas
Query, Connection and Document class
This is also easy to do, same case - both modules already use this
A views query plugin that allows to pull in fields from Solr so that we can easily create views and both modules could extend on top of this plugin. We should take a look at how apachesolr_views does this
This is hard and will require some effort
Facet API query classes, but search api should be able to override them
This is easy, and we should figure out common logic and see if we can even make them the same, where we both use a different data connector? Not sure about this one.
Facetapi has also an architectural issue where the searcher name cannot change and it becomes very hard to switch your facet configuration to another searcher. e.g.: From Core to Solr or Core to Search API

Indexing logic and why queue is not a good option for indexing items to your search

Loosely coupled from this connector module we also want to share the indexing logic from the apachesolr module because it became clear that using a queue is not suitable. Imagine a scenario where you have a couple of content editors and you save a node a couple of times Search API adds this node to the queue for as many times you save this node. Consequence is that is indexes the same node a numerous amount of times while not having any use since the content during indexing phase is always the same.
Addendum: It seems Search API does check of the entity is queued but it is still not an ideal situation.

This indexing logic should be separated a bit and should probably be embedded in Search API Drupal 7 and 8.

What else we could leverage from Drupal 8

Facet API blocks could become views where the way we display this information can be easily changed.
Numeric Query types should work for both modules, it seems there was a lot of work done in creating graphical visualizations. Figure out how both modules can use the work
REST API in Drupal 8 could and should be leveraged to return the search page as JSON or any format that is supported in Drupal 8. This could be beneficial for Saved Searches so that could be made more generic.