Introduce an asset search service similar to the node search service

[daniellienert]

While a service with an interface exists to search for nodes, searches for assets are directly wired to the asset repository.

Introduce an AssetSearchInterface with a default implementation using the repository method.

[bwaidelich]

big up for a central asset search, but IMHO an interface doesn't really make sense here.

I think it should go into the direction of what the flowpack/media-ui (and especially https://github.com/Flowpack/media-ui/issues/15) is trying to tackle: A simple-to-use API that can easily be changed without breaking old clients.

My favorite solution would be:

• Extend the neos/media package with a PHP API that abstracts all the repository, asset proxy, ... internals
• Add a separate package (e.g. neos/media-api) that introduces a GraphQL API that makes use of that new PHP API
• Use that API everywhere in Neos itself (possibly via the flowpack/media-ui package as intermediate solution)

[daniellienert]

Hey @bwaidelich,

It may be, that you misunderstood my use case and the problem I need to solve. The link editor and other search-as-you-type fields in Neos use a controller and then directly the asset repository to do a like search on fields in the database and returning unlimited results. That may work on smaller projects, but on a current project this takes forever and returns thousands of hits.

Adding that interface would make it possible to easily implement a more powerful search engine backed solution without breaking anything. That really makes sense to me.

Sure, it would be awesome to have a graphQL API "at some point in time" which unlike the current implementation in Flowpack/media-ui is not hard-wired to the repository. But introducing this API would be breaking anyway and you can get rid of that service at the same time.

[bwaidelich]

@daniellienert Thanks for getting back :) I think I got your point. I just mentioned GraphQL because work is being done there. My suggestion was not to postpone this ticket until that work is done!

The other way around actually: I'm all in for creating a PHP API first in order to easily manage (especially query) assets. And I think it's important that we stick our heads together because there are a lot of overlaps.

I just talked an hour with @Sebobo and we came across some fundamental challenges we face with the current implementation and that we should at least have a common plan for IMO:

• How to implement a scalable pagination (suggestion: cursor based)?
• Shouldn't Tags be Scalars (I want to do filterAssets(tag: 'some-tag') instead of filterAssets(tag: '<some-uuid>'))?
• Should AssetCollections be nested instead of Tags?
• Can we abstract the notion of asset proxies from the consuming side?
• Should we filter by AssetType (Image, Audio, Video, ...) or mediaType (image/*, ...)?
• ...

Some of those question would require more work but some could already be implemented in one or the other way and IMO we should do that in sync so that the GraphQL API can later use that new service