Designing the Search API about commuter HOT 7 OPEN

Brain dumping ...

As a user, I usually want to enter free form queries in order to get back a listing of notebooks matched on filenames, titles, tags, authors, markdown, or even code. I expect these to be weighted in some manner, preferring filename hits over code hits, for example. I don't want to learn a query language to perform simple searches. In rarer cases, I'd like to formulate more complex queries like language=scala AND Dataset. A simple query language would suffice here.

The API could be lightweight such that the user's query text gets passed to the configured index as-is and the index implementation makes all the decisions about how to interpret it. The API could be more explicit, requiring the user / frontend to provide more information about the query, and simplyfing the task of the index in interpreting it.

In either case, if a query language is to be supported, then all index implementations have to be able to support its features and, in the lightweight API case, perform the parsing.

from commuter.

API for clients of commuter to perform searches? Or API to plug different search back ends into commuter?

from commuter.

API for frontends to query against.

I'm fully expecting us to write different search backends. Right now elasticsearch is just the easiest for us to deploy.

from commuter.

If commuter were to expose a search UI, I'm assuming it would go directly to the index for results. If another client wanted to implement search, why would it query commuter instead of going directly to the index?

Not trying to be difficult. Just trying to understand the use case.

from commuter.

I'd rather not leave elasticsearch open for DELETE at _all or for modification by users.

from commuter.

Sure. I understand that. I meant "other web apps" by "other clients". Like, if I were to implement my own web app, I'd have the backend talk directly to the search index and guard against deletions and whatever else I didn't want to expose directly to users.

So, correct me if I'm wrong, you're thinking of the case where the client cannot be trusted, say, a notebook tool with a search feature built-in.

from commuter.

Yeah the backend would still talk to elasticsearch directly.

Are you saying we'd effectively proxy _search?

from commuter.