Firesearch.dev - Serverless full-text search

Documents

A document is an entry in an index. Documents have text fields which are searchable, and typed fields for advanced querying.

  • Document structure
  • Identifying documents
  • Search fields
  • Non-search fields
  • Document structure

    Here's an example document:

    Document structure varies depending on the type of index, see Doc and AutocompleteDoc.

    Identifying documents

    When you put a document into a search index, you must provide a Document ID string. You use the Document ID to update or delete documents.

    The Document ID is returned when that document is included in search results.

    Usually, a search document is a representation of another data entity with its own ID. So it often makes sense to use the same ID for both, or to somehow derive the Document ID from the source ID.

    Search fields

    A search field is a key/value pair where value is a searchable string in Firesearch.

    • value must be a string
    • The value is tokenized and added to the index
    • By default search fields are not stored in their original format, to preserve the value you should set store: true in the field

    It is common to have both a single body field.

    Depending on your use case, you may decide to break content down into multiple fields.

    You can use the searchFields array when querying to choose which fields to include in a search, which can be useful for narrowing down search results.

    An example is a song title search vs song lyrics search—both could go as separate fields into the same Document representing the song. Users could decide when querying whether to search titles, lyrics, or both.

    Non-search fields

    Fields allow you to store additional non-searchable data in your document.

    Fields can be returned in search results (if listed in the select list), and may be filtered.

    Filtering fields allows you to narrow down search results, often providing a much better user experience.

    A Field is a key/value pair, but unlike Search fields the value can be a string, a number, or a boolean (true or false).

    At query time, you can filter documents by matching values against these fields.

    Design for filtering

    To provide the highest possible performance, Firesearch only provides equality matching for fields.

    Any business logic or advanced querying should take place before the document is added to an index.

    For example, instead of a number field for the price of the product, you might have a priceGroup string field that has one of a possible range of values depending on which group the item is in; 0-99, 100-199, 200-plus, etc.

    What next?