 So, let's get started. So, hello everyone. My name is Florian Martin, I'm a CTO at Splendor, and today I'd like to talk to you about search. And I know this is a Drupal event, but for a couple minutes I'd like to take a step back from that whole Drupal thing and take a look at what are the expectations of our users when it comes to searching. So, let's look at a couple examples. Wikipedia, you probably know that, and when you search for Wikipedia, you start typing for whatever you're searching for, and no matter what you type, it figures out what you're mostly looking for, just when you jump straight to that thing, you still have the possibility to do a full text search, but by default that's not like the first option. On Amazon, you also have suggestions when you start typing that the suggestions are not results. These are actually suggested searches, so you have different completions that you go beyond what you typed, and then for specific suggestions, they're even combined with a specific category in this case, so that when you select that suggestions, you have the right facets already preselected in there. On Spotify, you can also search for Drupal, I was surprised that you do find something, but when you search something, you also have an auto-complete, and there you have all kinds of stuff that show up in the auto-complete. You have songs, you have artists, you have albums, you have, in this case, a playlist. So, you do have a full text search, but actually when, well like most things that you could be searching for on Spotify, you will find that in the auto-complete, and you will never use the actual full text search. GitHub, you also have a search there, it's actually quite simple, nothing fancy, but when you search in something, you are searching by default in this directory. So, there are millions of repositories on GitHub, and so there are millions of subsets that users search through. Nobody ever searches through the entirety of GitHub, even though you have also the way to do that. What's also interesting is that here, when you search, you actually get not only facets, but you get a visual representation of what kind of result set do you have. So, not only how many results do you have, but what kind, when you search on Stack Overflow, they're also, it's quite simple, but when you search for something, what's interesting here is how they are sorted. So, sorted by relevance, you see that maybe like the number of votes play a role, but also how many answers you have, and then this same search system is also what powers like individual tags, some depending on what kind of activity you want to do, whether you want to answer a question or ask a question or get an overview of something, then the different types of sorting actually play a big role in what is going to be relevant for the user. So what can you learn from these examples? Well, the first thing is that when it comes to search, there is no one size fits all. Every single project will have different data, will have different users with different needs, and it's important to adapt to the needs of your users, and you need small details that really matter. And these details actually take place at different levels of the technical stack. So you have the UI level where different facets, maybe you want to display your search results differently. You, like a lot of the example that I showed have auto complete stuff. So you have like the search itself that can be a pretty complex front end application in itself. Then at the application level, what kind of data do you want, how do you structure your queries, what are you searching for exactly, how do you prepare the data, and then obviously at the storage level, you need to store the data in a way that makes it possible to retrieve fuzzy searches from millions of entries in just a couple of milliseconds. And so you need adjustments, and you need like particular attention to detail at all of these different levels. The other thing that we can learn from these examples is that all of them are based on elastic search. Actually, there is one that I don't know that it is based on elastic search, and that one is Amazon. And the reason why I mentioned that is because a lot of people when they first hear about elastic search, they think elastic's something that must be an Amazon product. No, actually it's not. Elastic search is an open source project, just like Drupal. And yeah, talking about Drupal, what does search look like in Drupal? Well, we have a module in Drupal core that comes up enabled out of the box. Must be good, right? And actually this little screencast was taken from Drupal.com, that one. And so yeah, when you search, you get, you can search for content. Actually, well, you can search for exact matches in content that was created before the last time that Cron run, or before the last time. And you also have some advanced searches. Yeah, but this search actually functions better mentioned the same way as this search. Do you know what this is? Any guesses? Yeah, this is a Drupal 4.7, and why did I mention that is, well, if you look at the change log of Drupal, the last time that anything relevant change in the Drupal core system was actually in Drupal 4.7. It's taken pretty much the same since then. Just to put that into context, these devices do not exist by then. And this website was still very cool. So if you care about search, don't use the core search. Because the biggest risk you have is that users might actually try to use it. But the core search is not the only option. So already quite a while ago, this guy, Robert Douglas, and a couple of other people tried to push the idea forwards to use Apache Solar with Drupal. And there was a Drupal module of the same name that integrated Apache Solar with Drupal. Here's all the features that you provide from the official module page. But really, what were the main selling points? So the first one is that it's fast because searching is something that's really difficult in terms of what algorithms, in terms of scaling and performance. And so you need to have a dedicated system to be able to handle it well and to handle that in a way that scales. Second, Solar can do proper text analysis. So you can do stemming, you can do fuzzy searches, all the kind of things that make it possible to be tolerant towards your users so that they don't need to know exactly what words are in the thing that they're looking for, they can just type whatever they feel they're searching for and we can be tolerant towards them. And then Solar does facets. And facets, it's not only the widget, but it's also this idea that you start with a very generic keyword search and then you get an idea of what kind of results you have and then you iteratively refine your search by specifying different facets. And what's great about this is that you're always refining within the existing result set. So you never end up with a situation where you choose something that will have no results. And that's a great, that's really great UI concept. But somehow as a community, we got stuck on this idea that facets are really the essence of a powerful search. And yeah, facets are great, don't get me wrong, but there's a lot more to just facets. And I think these first few points here, the performance and really the text analysis and the tolerance towards your users, they're much less visible, but they are much more important if you want to build search interfaces that actually just work. Of course, I need to mention Search API if I'm talking about Search and Drupal. Search API, does anybody not know Search API? Okay, but yeah, in short, Search API does everything that Apache Solar does, but it provides a plugin system that lets you do that with other search backends and it also integrates very nicely with standard site building tools like Guse. And we've built a lot of very cool stuff with Search API over the years, but personally I had a couple issues with Search API. The first one is that it's an abstraction of solar. So it's not an abstraction of a search system and that's actually something that would be very difficult to do. It's an abstraction of the functionality provided by the Apache Solar Module for Drupal. So it's actually quite restricted. It lets you plug in, like replace solar with other systems, but that won't give you a much more functionality. Second, everything is based on configuration. And that's great because it means that you can just log into your site and just create all your configuration, how you want things to be indexed. But at the same time, there are certain problems that are better addressed with code than with configuration. And personally, I think that Search is one of those. And as a consequence of that, Search API implementations are difficult to customize. So it's okay to customize those if you can use the options that are available, but if you want to go beyond that, you need to hook into the Search API to then hook into the API of the underlying system so you really need to learn two different APIs to do some sometimes awkward maneuvers to actually do small adjustments that are in the end quite simple. But I'm not here to say bad things about Search API. I actually think that Search API does serve very useful purpose in the Drupal ecosystem, but I'd like to talk about Elastic Search. And the first contact that I had with Elastic Search was quite a few years ago when we built one very interesting application that combined Drupal and Node.js and Solar to do some document management for private users. And at some point, we ran into some really critical issues with Solar and we decided to give Elastic Search a try and within something like the day of work, we were able to completely replace Solar with Elastic Search, everything worked a lot better and we're like, hey, this is great. And you don't need to take my word for it. If you just look on the internet who is using Elastic Search, what people are saying about it, there's a pretty good consensus. And yeah, I mean, who is using Elastic Search? Pretty much everyone. A lot of huge companies. Facebook is using Elastic Search, Microsoft is using Elastic Search. And you're using Solar, well, Drupal people. No, there are some more, but the trend here is pretty clear. So what's great about Elastic Search? Actually, I'm not going to go through all the details. You can read up on the website, they have some very good materials there. But I think there's one point that is really important for the kind of work that we do as Drupal developers. And that's a developer-friendly RESTful API. Developer-friendly means that it's actually a nice API that you want to work with. Unlike, for example, Solar. And so it's so nice that you don't want to put it behind an abstraction layer like Search API, it's an API that you just want to use. And also, well, it's RESTful, that means that it works in the same way as the stuff that we do on a daily basis. So it's not some kind of like other kind of technology that's unfamiliar to us. It's something that we can just use and we understand we don't need to learn new concepts to do that. So we had this situation about one year and a half ago where a customer came to us and they wanted an internet. That was at the very early, like that was before the Drupal 8 release, we were just getting started with building Drupal 8 websites. But what the customer wanted, they wanted something that's simple. So very simple internet, but one of the main features that they wanted to have was to have Search. And that Search also had to be simple. You just start typing anywhere on the site. But it also had to be powerful. It had to search through users, search through content, search through the company counters that just comes from an external API. And at the time, Search API was not ready. And it was an implementation of elastic search for Search API. It also wasn't ready. And we decided to just create something simple. And this is what we created. This is some simple context. And to be a video player? Yeah. Okay, and so you start typing anywhere on the site and you can search for users. You can also search for content. And yeah, you just have the search overlay that pops up and just lets you wherever you want to go. So how can you build something like that, like a very minimal version of that? And actually, this is pretty close to the original implementation that we had. So first you need to install elastic search. How do you do that? You get it, you unzip it, you run it. That's not what you're gonna do on a production environment. That's probably not what you can do on your proper local development environment. But if you just want to give it a try, it doesn't get really much faster than that. And actually, if you want to do that in production, you probably want to use just packages that are available or Docker images, depending on what your infrastructure is. So getting up and running is really easy. Then the second thing, we need to talk to elastic search. It uses a REST API, but there's a very good library for it that you can use, you can install it just with Composer. So I guess everybody here is using Composer for your AAA projects, right? Yes, okay. And so you just do that and you're ready to start indexing content. So your content, we assume it's going to be in notes, which are entities. So the basic example on how to do that, we implement our Google entity update. We instantiate a client. Of course, you would put this in a dedicated service, dependency, injection, and so on. This is just the most minimal code to get up and running. So we connect to our posts and then we call the index method. We specify that we want to put stuff in it. And then the index called content, then in a type called particle. The type is to an index more or less what a table is to a database in my SQL terms, like very rough analogy. We can optionally give it an ID so that we can later on just refer to that entry. And then for the body, we just pass it the entity as is. The good thing here is that, hey, look, we have content in our index. The bad thing is that what we have in our index is this monstrosity here. We have a node ID which is an array of objects which have an attribute called value. And in that attribute, we have a number as a string. So this is not exactly the kind of stuff that you want to be having, for example, in your JavaScript front-end application. This is also not the kind of things you want to have in your search index. So what we do, we use the serialization API, more specifically the normalizers from provided with Drupal core. And so when we have an entity save, we serialize the data with a custom serializer and we put that into your last search. The result is that we have something like that. We have a label. This is a string. The user could be like an object with an ID and a name. It's like deserializing there. Images could be like a link directly to a specific image style. And what's great about Elasticsearch is that you can just send that and it will take it and index it like that. And you can get it back out in the same format, something that's, for example, not possible with solar. But sometimes you want to be more specific about the schema. So you want to say, for example, that with your properties, so you explicitly define a mapping. You say, well, the created property, yes, it is a number. But it's a number where it's a timestamp. So we want to specify that it's a type date and the format is going to be about seconds so that it gets analyzed like a date so that you can date, do date facets, date histograms, everything like that. Also, maybe the content, it's going to be specified as English so we get proper stemming. You can also specify other languages, like most European languages are supported out of the box. This is really useful. Sometimes you have fields like a URL. It is a string, but we don't actually want to analyze that. So we don't want to like split it into words. We just want to keep it as it is. So now we have our data that's indexed and how do you search for it? Well, we instantiate our client. This would typically be in a controller. We can search across one or multiple indices at the same time. So for example, for this example that I showed, searching through users, searching through projects at the same time, you can do all of that in one query. And then this is a little bit more complex, but this is actually pretty close to what we use. Of course, you would want to escape that. Do you not copy any code from these slides and put them in production? That's a bad idea. But it shows the basic mechanisms. So we take the input of our users. We pass this to the query. We search through the label and label.autocomplete fields. And what's happening here is that label.autocomplete is going to be the version of the label that's split up letter by letter. So you actually get this search as you type functionality that you get matches even before you've entered a full word. But if you do have a full word, so without the.autocomplete, then you're going to boost this specific result so that when you get exact matches, these will show up before partial matches. And then the fuzziness is usually it's a number of characters that can be off. So how many typos do you enable? And when you specify auto, it will just allow you to be, like, L6 search will just be more tolerant to the longer your input should be. And here, one small but really important detail, something that we learned through experiments, the prefix length. The prefix length is actually how many characters at the beginning of the string are exempt from that fuzziness. So how many characters are not allowed to be wrong? And this made our search a lot more intuitive. Let me show you one. So I have this example. I'm looking for my colleague, Tony. And I'm typing, Tony. And I see I have my colleague, Tony. I also have my other colleague, Tony. And of course, well, this one, it's a suggestion because maybe I mistyped the n and the n that's right next to each other and the keyboard. So that kind of makes sense. And then the customer was complaining that Donnie was showing up there. He was like, this doesn't make sense. Why is that showing up? And we said, well, actually, there's one letter that's off just like Tony. He was like, it feels wrong. And the reason is actually the way the brain interprets text and recognizes words. The first letter is a lot more important. And also, when you type something, the first letter is almost never mistyped. So if you have typos, it's usually later on in the word. So it's the small amount of, like, small level of details that actually when you put this graphic length, then Donnie would not show up in this list. And this is important to understand what is the purpose of that search that you're building. So when you're building an autocomplete like this, the purpose is not to surprise the user, to show stuff, hey, did you think about this? When you're building an autocomplete, you want to guess what the user wants to see. And so you want you to be just intuitive. The user will be typing and you have like a fraction of a secondary app and to just save a couple keystrokes. But this is not the place where you want to surprise the user. This is what the search result page is for. So yeah, this is what we built. It actually worked out really nicely. It was very simple. Customer was happy. And yeah, we were under budget. The team was happy. We decided, hey, this is actually working out really well. So let's use this for other projects. So here's another project that we built. This is a company that does paper and office products. And a typical use case, you buy like their print at home business cards from the store. Then you get a little code on the box that says go to our website, search for this, and you will get the template. So here we have the user that is dead, I guess. OK, so you go to website. You type your product code, and you get to the product. If you want to do parsing and other completion on product codes, of course that's going to work differently from a full-text search. So small things that you need to plan with. But also, some users come to the site not knowing about the product code, and they're just looking for something. And we want to do the same kind of thing that you have on Amazon that you're looking for business cards, and it gives you some suggestion for what kind of business cards are you looking for. So really suggesting searches for your users. And how do we do that? We actually use, well, the same kind of queries that you would do to get data for facets. So you do an aggregation. That's a more generic term for facets. And we call this Suggestive Terms. It's meant to be a terms aggregation on the field suggestions. We use the raw version because we don't want to analyze these. We actually want to get them straight as they were entered. And then we just include only the ones that match the input from the user. And then when we get the results, we just go through the aggregation, the Suggestive Terms, so we get the same key that we used, that we specified before, go through each bucket and just create a response like that. So custom code, yes, but something that's actually relatively easy, a couple lines of code. And this was working pretty well. And then we had one specific request from the customer. So I think everybody here is familiar with paper sizes. And one thing that everybody knows is that A4 is the more common paper size. And the customer asked that, well, if you have a product that comes in A4, A5, and A3, actually A4 should be the first product. How do you sort that so that 4 comes before 5 and 3? Well, we did this. So we had a boring query that combines our original request that the content should match our input. And at the same time, a should clause. So this is like, if you could do this, this would be great. If not, that's OK. And so here we looked at the size of the paper is size A4. And that makes it so that A4 products actually show up before. So they don't show up at the top, but the same product that's available in different sizes, the size A4 will be showing up first. What's interesting here is that this is specified at query time. So there's nothing stopping you from putting some dynamic value in here. So you can very easily build personalization based on this, either based on user references. It could be based on the user, the history of the user. And this is really powerful to build interfaces that really adapt to the user that just follow along as a user is just coming to your site. Another example here, this is a real estate tool for real estate professionals. You have all kind of parametric searches. But what we're using here, well, one of the features is that these people are really busy people. And they don't want to keep on coming to your site and every hour just search again and then see if there's something new. So we built some saved searches so that they get notifications whenever something new matches one of their searches. And if you've ever tried to do this, this is the type of functionality that doesn't scale well at all. The bigger number of searches you have, the bigger number of results, just running each search on Chrome, it really doesn't scale at all. So what we're using is Percolator. And Percolator is a coffee maker that was pretty popular in the 70s that makes apparently pretty terrible coffee. But it's what gave the name to this Percolator API in Elasticsearch. And a Percolator is a way that you can, the same way that you index documents, you can index searches. And later on, you can make a Percolator query where you give a document to Elasticsearch and you can tell it which of the saved searches would have this document here as a result. So it takes some time getting your head around that. But it's actually a really practical API that lets you do saved searches in a way that scales indefinitely or infinitely. And yeah, it's very simple, very easy to implement. And that gave us some very clean code. After doing a couple of projects like this where we had a small amount of custom code that was very, very useful, we realized, well, there are certain things that we could standardize. So we created this Elasticsearch helper module, which we use now on a dozen projects. And we've seen quite a few people adopting that as well and outside of Thunder. And so what does it do? Well, out of the box, it doesn't do anything. The only thing it does, it defines a plugin type. And when you instantiate that plugin, what you get is so you create a class that has some annotation, give it a name, label. And then you specify what's the index name and what's the type name. So just Elasticsearch index and type. And optionally, you can specify an entity type. And when you do that, the module will automatically index all your entities of that type whenever they get saved, updated, deleted, and so on. So you do that. And you eventually specify a custom normalizer if you want to have more control over how your data is indexed. And it just works. And if you want to do something different, when you're indexing content, when you're updating content, how you define your mappings, what you can do, since you're just extending that base class, you can just override any function. For example, if you want to do translation, you can say that instead of just calling the parent directly, you just go through each translation and then you index each translation separately in a dedicated index. So you get the same structure across all of your translations, all your languages. But at the same time, for each language, you will have language-specific analysis of text. So what's great about this is that whenever you need to do something, what you're using is actually the Elasticsearch API. So you don't need to learn any new API in order to use Elasticsearch helper. So the only API you need to learn is the Elasticsearch API. So it's very transparent. And using this, well, you can use the couple of examples that I showed before. They're using React or Angular Frontends. But you can also use this with very simple views based, like old style or classic site building tools provided by Drupal. This is a site we built for a Finnish customer. So you search for something. And this here is actually coming from a view. These are specific view modes. So really nothing very special that was created there. So it works for complex use cases. It also works really well for simple use cases. And one thing that is important to notice here and I think that this guy said it really well, yeah, search boxes are good for letting you find your results. But sometimes it's really important to get an overview. What kind of results do you have? And facets are a way to do that. Another example, this is from a project that colleagues in Belgium did searching for student housing. So when you display things on the map, it actually gives you an idea of what kind of results that do you have. Or all of these things in one place, how far apart are they spread. And this is really useful in terms of getting an idea. Am I looking for the right thing with the kind of search criteria that I entered? Now there's actually another project that I'd like to talk about. And this is Schlozscheck. Schlozscheck is a large shop for sporting goods. So one of the biggest in Germany, both with physical stores and also online. And they have something like half a million products. And so they have dedicated teams that just manage like SEO data for these products. And it's so much data that is difficult to just manage. And just having a list of all that is not really useful. And so we built a tool for them to let them analyze the data they have and manage it so that they can assign entire product categories to dedicated copyrighting agencies. And here this actually looks like a very classic Drupal backend listing. But actually this is coming from Elasticsearch. And one of the reasons why you pull all of that data out of Elasticsearch is performance. So for listings like this, yeah, it works. Confuse actually works. But if you have a listing, like let's say, with 32,000 entries, which we do have for some kind of listing, views completely chokes. It cannot handle that. And Elasticsearch in this case is so much more performance that it's not only faster, but it makes things possible that would not be otherwise possible that would require a really complex batching process and things like that. And so in this case, it makes it possible to do listing like this, but also to provide more interesting visualization that, again, give an overview of what kind of content we have. So in this case, the admin can go through the product categories and assign, for example, the category Nordic walking to a specific copyrighting agency. And so this actually gives you a very good idea of what kind of stuff I'm dealing with. And the data for this tree, after a good amount of optimization loading the data from the entity system, it took two seconds. I think actually, yeah, two seconds, that's long, but that's OK for this kind of scenario. And then we switched to Elasticsearch and getting that same data to like less than 200 milliseconds. And actually, the 200 milliseconds was mostly Drupal bootstrap and transferring the data. So that's the kind of stuff that's like, I mean, it's really at least 10 times faster. And the more data you have, the more you'll see a difference. What's interesting in this case is that we are getting data from elsewhere. So these products are not Drupal entities. They're coming from elsewhere from different systems. And what we do, we certify that data and treat it Elasticsearch. So we don't put everything in entities. We can just get data and put it straight in Elasticsearch and use it directly there. And what's interesting once we have this data in Elasticsearch is we can enable Kibana. And Kibana is a data visualization tool that lets you create graphs easily of all your data. It's used a lot for monitoring, log monitoring. But you can just put any data in it. This is a tool that we put in the hands of our customers. So they can create custom graphs and explore the data they have on their own. And this is really powerful if you want to have a good discussion about the data that you have engaged with your customers, like when it's relevant, what can you learn from the data. And yeah, Kibana, you can install it just as quickly as Elasticsearch. And what's great is whenever you use Elasticsearch for searching, then you can use Kibana. And we have cases where we use this for just a project that we took over. There was some existing data. And based on just a couple of graphs, we were able to tell the history of what people have been working on that site at what times, who were the admins, who was responsible, and tell the history of the site actually better than the people at their clients could, because we were able to visualize the data and say, hey, look, this guy worked here. And then he left the company. And that's when the other person took over and so on. So even with small data sets, it's really amazing, sometimes, the kind of data that you can get out of it when you have the crocodiles in place. And now we're actually getting to the beyond parts of search. Most of the examples I showed, well, we have Drupal. We send data to Elasticsearch. And then we ask questions from Elasticsearch to what the new query is. But that's not the only scenario that it's useful for. We've seen quite a few cases, especially in the media and publishing sector, that we have one entity that, one Drupal instance, that is a content management system that pushes content into Elasticsearch. And then we have another frontend instance that actually queries Elasticsearch. And this is where all the content aggregations and placements, all of that happens. And here, this is where the editors or the journalists or whoever's writing the content is working. So that's something that's quite powerful, this kind of separation of concerns. But there's nothing that specifies that this should be Drupal. Maybe it could be, like, Sylex application, like, lightweight, symphony stack. It could be Django application. We actually have a customer that's like a video game company that you probably know. And they're sorting this content for their website through that. They're also sorting the content for the games through various gaming console. Any gaming console that you can think of, they're on it. And all the data is coming originally from Drupal through Elasticsearch and being delivered through a different technology. And so you're using each of these tools at what these tools do best. So Drupal is good for handling management system. But if you're talking about a REST back end for applications, I mean, we love to talk about the REST's module, but realistically, it's not the best. And then you also have other possibilities, like Internet of Things. Maybe if you want your toaster to talk to some kind of data store. Maybe actually Drupal is not the best back end. Maybe Elasticsearch is a better back end. And just to include a couple of best words, well, if you want to create a chat box or some kind of conversationally interfaces, actually Elasticsearch is a much better back end to ask the kind of fuzzy queries that the user will ask. And so if we need to put something in the center of our multi-technology stack, maybe in the middle it's better not to have Drupal but Elasticsearch. And I think this is something that's quite powerful. So when we're talking about decoupled infrastructures, well, if you're putting a Drupal-specific JavaScript code in your front end, is that really decoupled? I would say no. And I think with something like this, it's a lot easier to say, well, replace Drupal with another content management system, replace your front end with another one. And yeah, today we're good at building websites. And people will say, web application, platforms, and so on. It's all stuff that opens up in your browser. And there's some interesting intersection between website and search. But there's a lot bigger thing beyond just websites. And I think it's important to get good at that part, too. This way we will have a job and an interesting one, even when websites are obsolete. So in summary, I think that, well, search matters. And search matters to the point that you need to pay attention to details. And you need to have the right adjustments in the right place. And that's what's going to make a difference between a search that your users fall back to using when really needed and a search that your users will use without even noticing it. And Elastic Search actually has a really expressive API that lets you easily create those adjustments that really make it possible to create these kind of experiences. And the difficulty here is not learning the API. That's actually really easy. The difficulty is learning the concepts, learning how do you do that. And that's kind of, yeah, it's a challenge because these are things that need to be really intuitive. But we need to understand how that exactly works. But one thing that is clear is that Elastic Search is fun. And to me, this is really what motivates me to just come to different events and talk about Elastic Search. Because if I come home at the end of the day and I'm really happy about the technology that I'm working with, this is a whole new level of value. And I'd like to thank a lot of people that have worked with Elastic Search that have told me about their challenges, their use cases, their bugs, their bug fixes. And I hope that you also learn something today that you will get a chance to play with Elastic Search and to build cool stuff. And if you have anything that you build that is cool, definitely like me now. Because I'm very excited to hear about it. Any questions? The scenarios where another service that does search is such as Google Places. That's one big place to bring some results like. We've had those scenarios where Elastic Search could play with another search team and more than the original thing. Not really. But one of the use cases that I could imagine is that you search through the results that you have. Then if you don't find anything, you actually fall back to using something that's wider. And we actually have a couple of cases.