 In this community world of e-solution where almost every e-solution has some alternative to choose, providing the right content through the right search and browsing experience is the key. Think about Spotify, LinkedIn or Amazon. Everyone wants to find right songs, people and products in just a couple of keystrokes. Building an interactive search interface can be challenging for developers. It may take several weeks to just create a prototype. In this talk, I'm going to present to you how we can build production-ready search apps in time frame, ranging from few days to sometimes even less than a day. Hello everyone, I'm Kuldeep, currently working with fbase.io as a senior software engineer. I like to explore new frameworks and languages. I'm the co-author of reactive search and also authored some open-source library for react and react data. So what are data-driven apps? If your app extensively relies on the data, that data can be coming from any REST API server or any other platform on the internet, then we can call it a data-driven app. An e-commerce example will be a perfect use case, perfect to understand the use case here. So let's look at, I'm going to use minse.com as an example to understand the use case here. So this is a search page. I already made a search with search term name as Shoosh for men. So you can see the UI. Here we can see a set of results, and there is a sidebar where it shows some filters. We can select these filters to make search stricter to get more relevant results. So this is the category filter, which shows some categories as suggestions with some count values. And there is a brand filter below, which looks like same as category filter, but it filters the results by brand name. So just going to play with it and select brand name here. So you can see that as I selected the brand name, the results got updated as well as the side filters. And we can also observe that now we have fewer suggestions for the categories and the count values are also got changed. When we think of this from a developer's perspective, then we can imagine that each filter component is a standalone component, which is talking to the other filter components. And as I selected the brand name, it notified to the other filter components that brand name X is selected. And we should also notice that these components are talking to the server. Like when they get an update, they talk to the server and get the new results according to the selected filters. Go back to the slides. We just saw a typical example of the observer pattern, where we had a set of filters and a result component, which were dependent on each other. If you have to build it on your own, then it can take a lot of time and effort. We can conclude that to build data-driven apps, we have to remember the component to component communication. The component should be able to talk to the server. Also, we cannot ignore the UI component. Let's suppose a scenario where a user has to shop for an iPhone. And they typed the query, but they didn't get any results. Because maybe they mis-spared the word iPhone. It's good for the user, because they don't have to sell their kidney to get a new iPhone, but it's bad for the business. Nobody likes to lose business because of these kind of scenarios. If you are serious about search and looking for some advanced search capabilities, then Elastic Search is for you. Elastic Search is an open source search and analytics engine, which allows storing, search and analyze big volumes of data quickly. We are talking about milliseconds here. It uses a document-based approach to store the data and stop relational data, like in relational DB, we use the tables. And Elastic Search supports the full-text search. A full-text search is a search method where every search request, every word of the search request compares with the every word within the document. Why Elastic Search? Because it has the powerful query diesel feature, which is also known as the domain specific language, which allows you to write a query in the front-end and get the results based on the query structure. You can think of it as a similar, like we make a query in GraphQL. And we can also do the data aggregations, like if you want to show some data aggregated by country or some date, then it is possible with Elastic Search. Elastic Search is a great choice where you have to deal with casual search, geosurge, and autocomplete. Elastic Search uses the index to store the data, so we can use it to store the documents which have the same characteristics. For example, we can have an index to store the products. This is a basic example of an Elastic Search query. This is a match query of Elastic Search, which returns all the documents for which the title field matches with the search term as Harry Potter. So what are the challenges to build data determinants? One is that you have to implement the observer pattern on your own, and the other is that you must know what kind of Elastic Search query you want to make, and the query must produce the relevant results. So about two years back, we launched a library called Reactive Search, which can be used to build data determinants with Elastic Search. It is quite popular now on GitHub with more than 3.5k plus stars. Let's see in detail how we can use Reactive Search to build modern search shifts. There are 20-plus Elastic Search hosting providers in the market, and you can also host it on your own. A little bit about MSIO, we provide Elastic Search hosting as a service. If you don't want to host it on your own, then we will do it for you. Apart from the hosting, we provide streaming security and analytics, which can be used to improve your overall search experience. Initially, the Reactive Search was able to just connect with the MSIOF, but from version 2.2, it supports any index hosted anywhere. Let's see Reactive Search in action. This is the one-time setup you have to do before using the Reactive Search component. Reactive Base is a provider component where we have to define the index name, from which we want to make the search operations, and you have to define the credential if you are using MSIOF. Once we set up the provider component, then we can use the Reactive Search component seamlessly. This is the data search component. Before going forward, I would like to tell you that I am going to use the Book Search app as an example and I will be using it further to explain the code limits and examples. This is the data search component with bare minimum configuration, which renders a search work with auto-suggestion. The use case here is to render a Book Search search work, which can show some suggestions based on the user-type query. I have defined a component ID here. All the Reactive Search components are driven by component IDs, and they must be unique. I will discuss it later. The other problem is the data field, which allows you to define which data you want to run your last search query. You can see that these two or three lines of code just generate a beautiful auto-suggestion component, and you don't need to interact with the elastic search. This is the example of the result component, where we are rendering a set of a list of books. Similar to the data search component, I have defined the component ID and data field here, and just rendering some markup to render a particular result item. Here you can see that the result list component is also a part of the library. It is a multi-list filter. The same props I have defined, but the component ID is different. It generates a filter which can show a list of authors with some count values. One of the key ideas behind the Reactive Search is to allow users to define how their components should behave when they are updated in the other components. You can see that we have two components. One is the search component, which has the component ID as Book Search, which can be used to search for books. There is a result component for which I am using the component ID and the result list, which shows the list of results. By default, there is no dependency between Reactive Search components. If you make some changes in the search component, the Reactive List component will not make any changes in the UI. This is the same kind of observer pattern we have to implement here. Reactive Search handles it well. You have to define a React Prof here. You can see that in the result component, I want to list in for the changes of the search component. I just defined the component ID of the search component in the list component. I am just going to share a quick demo with you. I hope it is visible to you. This is the Reactive List component. I initialized it. This is some markup here I am using. Just remove it now. Some layout markup. I am going to use the data search component. It renders a search component here. For the second component, I am going to use the Reactive List here, which renders a list of results. I am just going to add some more filters. Let's add a multi-list filter. This is a single-rain filter by which we can filter the results by ratings. Now it is time to make some search. You can see that it shows some suggestions. We can select it. The results got updated and also the sidebar filters. This is the same kind of experience. We can build it with just 100 lines of code you can see here. Reactive search is different from the traditional UI library. It implements a component-to-component communication, component-to-server communication. You don't need to be an expert. You don't need to interact with Elasticsearch. Let's have a quick overview of what Reactivesearch offers. It has a 25-plus UI component, a component for everything like a full list, range, date, dates, components, etc. It also provides an easy class injection. You can customize your application with class name and style props. You can also customize the sub-components within a class prop. You can also define a theme object, which can be used to simplify your whole application. We also provide the query customization support. If you are not familiar with Elasticsearch, then you can change your queries. For example, here I want to show a list of cities which will be filtered by a country named India. I defined the custom Elasticsearch query, which is a term query. It is possible with Reactivesearch. It also supports the server-side rendering. You can create any React component to the Reactivesearch component. It will be able to talk to the other Reactivesearch components, and it can also make the Elasticsearch queries. We just saw that 100 Lens of code can build you a complex search interface. It saves you a lot of time. Initially, we started with React, and now we have Reactivesearch for Reactive. We have Reactive Maps, which provides a set of components, which has the Maps component. We also launched the beta version of Reactivesearch for View, and we are planning to roll out the stable version soon. Let's have a quick look. Recently, we did a 3.0 launch. We focused more on customization capabilities with Reactivesearch. We defined a lot of render props and control call-webs. We added the built-in support for voice search in search components. Now you can communicate with Elasticsearch GraphQL server, and we also did some major accessibility enhancements. Instant search is a similar project, which does a similar thing, but it is only for the Algolia apps. Searchkit is another library, but it is not well-mended, and their power users have already migrated to Reactivesearch. Reactivesearch is used by companies like Facebook Research, NASA, U.S. Labor of Department, and hundreds of small and medium companies. Whatever I discussed is open source. You can find the reference here. You can follow me on GitHub or Twitter by using the BIT code. Thanks for the time and opportunity.