1 of 28

Session

Search API Decoupled

2 of 28

Christoph Breidert

Co-Founder, R&D

Speakers

Artem Dmitriiev

Senior Lead Developer

3 of 28

Agenda

  • Why decoupled search?
  • Why Search API decoupled?
  • Current status and examples
  • How to contribute

3

4 of 28

Why decoupled search?

  • Because it is nicer than coupled search
  • Some tools we have used
  • Problems we have encountered
    • Too many APIs, too much specialised know how
    • Updates of APIs (for example Elastic 6-7-8)

5 of 28

Why Search API decoupled?

  • Search API abstracts the search backend (works with any)
  • Search API handles compatibility with updated backends
  • Search API is platform independent (Acquia, Pantheon, …)
  • Search API is powerful and feature rich
    • Easy configuration
      • UI for building and managing indexes
      • Facets, Autocomplete, etc.
    • Powerful API
      • Alter indexed data, queries, results
      • Plugin architecture

​

6 of 28

Decoupled + Search API = Perfect solution

7 of 28

Why not Search API views with Ajax?

8 of 28

Alternatives to default Search API integration with views

Search API pages (https://www.drupal.org/project/search_api_page)

​

Already decoupled:

​

Alternatives are based on retrieving Drupal entities

Only views and GraphQL allow direct results from search backend

9 of 28

Our approach: re-use as much as possible

Search API modules family has a lot to offer:

  • Facets, autocomplete, tons of pluggable features that can be extended and altered.
  • Search API Decoupled tries to benefit from using the same contrib modules that you normally use but in out-of-Drupal scope.
  • Basically module is just a glue to combine all the useful module features in one easy and friendly way for quicker start of proper search experience.

10 of 28

Admin UI for search management

  • Everything already there: Search servers, indexes, facets, autocomplete.
  • Numerous field pre and post processing during indexing and query time.
  • All facet and autocomplete settings that apply to “normal” rendering is still possible to use.

11 of 28

The cost of fast search responses

Only data from the search index is returned, and not from Drupal.

  • increased storage capacity for indexing the search result display HTML of the indexed entities.
  • index has more fields than what are needed for analysis and search itself (for example the name of a field, that is needed for displaying).
  • indexing should be done immediately or with high frequency to avoid. displaying stale results or results that user should not have access too.

12 of 28

Advantages of not loading entity during search results display

  • Less storage for cache, because normally each search will produce its own version of entity cache record, e.g. for excerpt.
  • Less load on database.
  • Almost instant search results display, because it is already there in search backend.
  • Possibility to define what fields to expose in response and construct the display base on them.
  • And as any decoupled solution - opportunity to use any technology stack you prefer, no need to know Twig or Drupal.

13 of 28

UI module for controlling search display

DEMO

14 of 28

15 of 28

16 of 28

Available UI elements and Layouts

UI submodule provides 3 default layouts: one, two and three columns defined by layout_discovery module. It is possible to create your own layouts, just add category “Search” to definition.

​

Default UI elements:

  1. Facet (needs facets contrib module)
  2. Search input (with or without autocomplete (search_api_autocomplete))
  3. Pager
  4. Search process summary (how many results in total, how much time it took, and so on)
  5. Search results display

17 of 28

18 of 28

Configurable UI Element

  • Each UI element can have its own configuration if needed.
  • It is also possible to not have any configuration like “Search Summary” plugin.

19 of 28

20 of 28

Facets

Every endpoint provides search api display plugin that makes it as a base for facets source entity. This way it is possible to create facets per endpoint, the same way as facets per view.

21 of 28

22 of 28

Placing search app on a page

23 of 28

Blocks provided by UI submodule

Search API Search Block with redirect

​

This block is has search input (optionally with autocomplete) and automatic redirect to search results page on submit.

​

Search API Endpoint

​

The main block that includes the JS client. This block exposes drupal settings with all configuration that was done on “UI” tab of an endpoint.

24 of 28

Configuration: drupalSettings.search_api_endpoint

{

"block-searchapiendpointdefault": {

"id": "default",

"label": "Default",

"base_url": "/api/search/default",

"elements": {

"021b5989-314d-45bc-a6bd-bbf28b483d4e": {

"id": "021b5989-314d-45bc-a6bd-bbf28b483d4e",

"type": "search_input",

"weight": 0,

"behaviors": {

"filter": 0,

"url": 0

},

"widget": "autocomplete",

"settings": {

"placeholder": "Search for contents",

"filter": {

"label": "Your search"

}

}

},

…

25 of 28

Response�/api/search/default?f%5Btype_0%5D=type%3Apage&q=fox&page=0

  • {search_results: [{,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}],…}
    • facets: [{label: "Category", key: "category", count: 0, active_values: [], results: []},…]
    • max_score: 12
    • search_results: [{,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}]
    • search_results_count: 25
    • search_results_page: 0
    • search_results_pages: 3
    • search_results_per_page: 10
    • took: 114.34

​

26 of 28

How to contribute

27 of 28

How to contribute

  • Build starterkit app
  • Suggest and �collaborate on �features
  • Review, document,�test

28 of 28

Thank you for joining us!

Stay connected with Drupal Austria for more exciting events, news, and updates!

Also visit our website: https://ddd23.drupalcamp.at/

​

​

​

And don‘t forget to visit our sponsors' stands.

Their support helps make events like this possible!

​

​