# Peek inside the Drupal Search API blackbox

<small>*Disclaimer: I'm the developer of the Search API Generic Devel module*</small>

The [Search API](https://www.drupal.org/project/search_api) module is the de facto standard of adding search to a Drupal site. It supports [many search backends](https://www.drupal.org/docs/8/modules/search-api/getting-started/server-backends-and-features#backends) and has a built-in internal Database backend, that is great for testing and smaller sites. It also has an impressive amount of [index settings](https://www.drupal.org/docs/8/modules/search-api/getting-started/adding-an-index), field data types, [processors](https://www.drupal.org/docs/8/modules/search-api/getting-started/processors), and the ability to integrate with [facets](https://www.drupal.org/project/facets).

These are all necessary to make a complete search experience, even creating a simple searcher requires you to manage (and understand) many of these options.

This makes it a daunting task to create a search index. I know I didn't feel comfortable, working with the Search API module at first, and have since revisited my first implementations to change the most glaring beginner mistakes.

One of the (my) biggest challenges is not knowing what entities had indexed what, and if they had been indexed.

## Enter the [Search API Generic Devel](https://www.drupal.org/project/search_api_gendev) module

After installing the module, there should appear a new *Search API* tab under the *Devel* tab on an indexed node (or any entity that is being indexed by any Search API index).

![A node that hasn't been indexed yet](https://cdn.hashnode.com/res/hashnode/image/upload/v1667473104087/C7UlfKmkf.png align="center")

### Try it yourself

The screenshot above is from an [Umami installation](https://www.drupal.org/docs/umami-drupal-demonstration-installation-profile), where I've installed *search_api_gendev* and the *search_api_db* module.

You can use [Simplytest](https://simplytest.me/) to try what you see in this article yourself (or spin up your own installation).

Enable the *search_api_db* module and import the config from [this gist](https://gist.github.com/BirkAndMe/7ceed756bfdfa49a0f1dc16399288b91).

Using the *Index item* and *Delete item* actions will do exactly what you would expect. Try them out and see that there's now content in the *Indexed data* container:

![Node after data has been indexed](https://cdn.hashnode.com/res/hashnode/image/upload/v1668085309659/Ba-XFkEDo.png align="left")

## Not there yet

You'll notice that the *Local data* is updated immediately when altering the entity, which is to be expected, but you'll notice the *Indexed data* is also updated. This is because it simply loads the *Item*, and it doesn't fill it with data from the backend (the backends don't have a uniform way of returning this information), however, some backend implementations will include `extraData`, that could hold the data actually indexed.

### The extraData

Depending on the backend server used there's be access to more information. Some backend implementations will add more data to the `extraData` property of the indexed item. The `extraData` is shown in the *Indexed data* container if any is provided by the backend server implementation (the [Solr module](https://www.drupal.org/project/search_api_solr) will provide extra information).

## Conclusion

Even with the shortcomings (of not being able to see exactly what every backend has actually indexed), I find the [Search API Generic Devel](https://www.drupal.org/project/search_api_gendev) module extremely useful. Getting a view of what the *rendered HTML output* is has helped me debug a lot faster than previously.

It also eases the onboarding of new developers that haven't worked with the Search API before, which is a huge win.