WIP FEATURE: Configurable node search service

[Sebobo]

Just a WIP idea to make the NodeSearchService fully configurable, so it doesn't need to be fully replaced by a plugin, but instead calls a list of resolvers which can accept a term and return results.

Its unclear whether this service will still exist in 9.0, but having a concept for a configurable service might still be good in the future. This one helps me right now a lot in a real project.

Checklist

• [ ] Code follows the PSR-2 coding style
• [ ] Tests have been created, run and adjusted as needed
• [ ] The PR is created against the lowest maintained branch
• [ ] Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• [ ] Reviewer - The first section explains the change briefly for change-logs
• [ ] Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[Sebobo]

@bwaidelich this is the idea I mentioned regarding a configurable resolver based node search service.

I understand that the API might need to be different if we want something like that for the future. For now I'm using it in a project and will collect some insights.

[bwaidelich]

Disclaimer: I might misunderstand the purpose of such an API (maybe it would help if we clearly formulated the scope and goals).

It's a really hard task to come up with a general API because there's a high risk that it's either too specific to the implementation or too abstract. And it can only provide the common denominator of features that all implementations support (e.g. elasticsearch provides aggregation features, but other implementations might not).

With Neos 9, we'll already have a quite capable search built into the core model (ContentSubgraphInterface). It even comes with a "query language" for property values.

So personally I would not be happy about a new core concept for 8.4 that will most probably not survive with 9.0.

Why not provide a 3rd party package that you can install if you want to re-use that specific interface?

[Sebobo]

I would do that if that package would survive 9.0 without too many changes 😉 Meaning, there would be a service I can override.

There are already a few package overriding the current service, so it would make sense if they follow a common interface so they can enhance each other. Resulting in a "find a node in any way you might want" way.

F.e. I implemented a resolver here that can resolve uris to nodes with the help of the router. The CR search wouldn't help me in this case (I think). But depending on the project the uri resolver has to have a custom implementation or require a second resolver, as in my case the Neos Uris and the actual frontend Uris for visitors are not the same.

As long as we have several ways of identifying a node in the frontend, error messages and wherever else, IMO it's useful to offer the capability of finding those nodes via a common endpoint.

I can't imagine that our CR search can give the same performance and quality of results as a fulltext search configured for a project.

On the other hand its confusing that the reference selector uses the same search in 8.3 as its searching for content and documents, and most searches are optimised for documents as aggregates.

Probably better if we have a call 😉

[bwaidelich]

Resulting in a "find a node in any way you might want" way

A common interface that doesn't have a clear API nor behavior does more harm that it helps in my opinion. For example: if you just accept any string as input and the output depends on the resolvers, you basically have a very extensible but quite useless API because the behavior is a black box and can change any time.

F.e. I implemented a resolver here that can resolve uris to nodes with the help of the router.

That's a good example and I think it makes sense to support URL-Lookups in the default Backend search vor example. But do we really want to enable 3rd party packages to change the behavior (and performance!) of this central search API at will?

I can't imagine that our CR search can give the same performance and quality of results as a fulltext search

No, it won't be able to replace a proper search engine in all cases. But I'm confident that it will be pretty fast for the general use cases. And for the others I don't think that the solution is a common interface, but rather a different entry point for this scenario.

If we were to introduce a central API, we should define input and output more precisely IMO otherwise it won't be much better than the current NodeSearchService. For example: what about limit/pagination? Is an array of nodes really the best result type or would we want some grouping/aggregation? ...

Probably better if we have a call

Yes, anytime! :)