 So, I think everyone has already settled down and quite aware like what I am going to speak on. Do you guys have any idea like what I am going to speak on? You almost have read the, at least the title of the talk, right? Okay. So, today I will be speaking about powering SUSI AI web clients with React and Redux. So, there are few keywords out here which may be familiar to people, maybe web clients, React, Redux. So, we will maybe dive deep into it in the talk. So, let me speak about myself. I am Akshath and I am an active open source contributor for FOS-Asia. And I was a student developer for FOS-Asia during the GSOC, that is the Google Summer of Code 2018. And apart from that, I also mentor for FOS-Asia in the Google Code-In Contest which are for the junior age group around 13 to 18 years and also for the Code Heat which is a competition organized by FOS-Asia itself. And like professionally, I work as a web engineer at Uber. So, you all can reach me out at these links if you want. So, yes. So, the project which I am going to talk about, it is SUSI.AI and it was the project under the Google Summer of Code which I had worked like during the Google Summer of Code for FOS-Asia. So, the first question that comes to the mind is what is SUSI.AI? So, any clue anyone like what is SUSI.AI? Everyone is talking about SUSI.AI everywhere, there are stickers and so, yeah. SUSI.AI is an intelligent open source personal assistant. So, if I try to explain you in a more familiar and naive terms, it may be similar as the Amazon Alexa or the Google Home. So, SUSI.AI is an intelligent open source personal assistant which is capable of chat and voice interactions. So, basically we have the chat platform for SUSI.AI where you can ask your queries and similar to the other platforms and you can, and it is capable of both the chat platform which is the text platform and the voice input as well and it can perform various actions. It may be like searching on the web, you can search for images, then you can check out the weather if you want and so, these basically have a architecture which it works on and you can query things which are actually fed into the system. So, moving ahead. So, why did we, like, what was the need of maybe building SUSI.AI? So, if we go into the goals, like, why, what are the final goals that you are aiming for? So, firstly we need a free assistant. As I already spoke about, so we already have Amazon, Alexa, Google Home, those are all proprietary softwares and we do not have open source alternative for these. So, here comes SUSI.AI, we are offering an open source free assistant and people are nowadays, like, it's very boring to type and then express everything, right? So, conversational web is the future, like, we just want to, like, maybe talk to some device or something and then let our, like, get our work done. So, that is the point and it is also very expensive to develop own solutions. Like, Google is a very big company and maybe Amazon is a very big firm. So, they can, they have the money and the manpower to actually do that. But what if you want to, like, set this up for your own organization, maybe a startup or even smaller size organization? So, that is one point and it is highly, like, customizable. Since it's open source and we have given the flexibility to actually, we have given the flexibility to customize each and every point as, because since it was made with the intention, like, it will be open source. So, we have kept in mind that each and every organization can actually use that and then take advantage of that. So, like, we'll be speaking about the Suci.ai architecture. So, yeah, this is it. And we have the Suci.ai server in between, as you can see in the center of the slide. And it is actually our backend server which exposes the various API endpoints and it follows the rest architecture. So, in the center, we have the Suci.ai server. And server basically has various skills and it is, and skills is also in a form of a gate repository. So, you can directly actually contribute to the skills part as well. And the skills, and the skills CMS. So, we have a web client called the skills CMS, which is actually the, maybe the marketplace as you call or the directory for all the skills that are actually offered by Suci as of now. And we have various and behind the hood in the server, we have the console. So, we say then various system components like authentication and the CMS which actually makes the server up and running. And if we come to the client's part with which actually the user interacts, we have various clients like the web chat, we have the Linux app, we have the Android app, iOS app, then various extensions and messenger bots as well. So, if I try to explain what is the actual workflow behind it. So, if suppose I'm a user, I'll go to any of these clients which is actually available. It may be the Suci web chat, it is like hosted in chat.suci.ai. Or it may be any form of the other bots which is actually integrated already. So, you go ahead and then type any query. So, something like what is the weather today? So, what happens is the API called from that goes to the server and the server processes it based on the skill gate repository that we have. So, we have a Suci mind which actually processes and gave us the right information based on what skill it matches to. So yeah, Suci AI server, then it actually processes it and returns a JSON to the clients. So, now the clients can actually display whatever you had queried for and then this is how it works. Yeah, so I talked a lot about skills, Suci skills. So, what are actually skills? No, they're not interchangeable like they're not compatible cross-platform, it's not compatible yet. Yeah, so as I talk about skills, so skills are the fundamental logic or the working you can tell behind the Suci. So, if I tell in the Suci CMS, we have multiple skills. Like it may be a weather skill, it may be a horoscope skill, it may be some like somebody likes to watch movies. So, you can get a movie recommendation skill. So, skills are the tiniest feature that Suci actually has. And the collection of many skills actually fed into the Suci servers, which actually returns the query that we want. So, this is, I didn't get you? Yeah, yeah, you can do it because yes, you can do that on your like- If I have old skills- Yes, you can do that. Yeah, I'll take up questions after the session, then we can have a proper discussion. So, yeah, the scheme to organize skills. So, we actually need a proper structure, how we'll organize skills, right? Then only we can actually frame it. So, we have a naming such as model, group, language, and then skill. So, the model can be of type public or private. Maybe you want to create a skill which is, you don't want to expose it to the, all the public and like, you only want to keep it to yourself. So, you can actually define those modes in the model. And then the group, we have various kind of categories. So, a skill can be a communication skill, it can be a new skill. It can be a place, like sports skill, anything. So, group actually divides bifurcates in these criteria. Then we have language. So, as it is open source, so it will be used around the world. And we have multiple kind of languages actually spoken around the world. So, we actually have, after the criteria, we also have different languages skills. So, we have skills for English, Hindi, like all the languages around the world. And after that, we have the final skill, which is basically a text file, which looks like this. So, it is very user-intuitive and very easy to understand, a lot of format. So, suppose if you log into Suzy's skill CMS, and then you want to create a skill. So, the format will be, you'll write your name, that just a credit part. Name, author, URL, description, dynamic content. And then this is how the user interaction part looks like. So, you can actually write user query. And this is just a sample query, but we have different patterns and various logic that you can actually fit into the skill. So, just a basic example, if I speak, if you write here high, just high. And then the next line, if you write, hi, I am Suzy. This is the simplest skill that you can create. And when you deploy it, you can save it. And then what happens is, when you actually write high on your Suzy client, the API request will go back to the server. And then the server will process it, and then find that this query was actually made into your skill. And then it will return the query as per what was written in your skill, and then all the other metadata. This is how it works. So, talking about the Suzy web client, so we have the chat client, I would like to show that. This is how, this is the most basic skill that Suzy offers. You say hi, and then it says hello. And it also, as you can see, you can see a up, upward and downward option in the response. So this is how we are planning to actually retrain our system so that it can also sometimes give not that correct answer, which is not 100% correct. So we are planning to use this data which is stored in the form of logs. And then actually give correct output to the users, which is sort of a feedback mechanism. Yeah, so now talking about scale CMS, as I already talked, scale CMS is the directory for all the scale that Suzy has. So as I discussed, we have various groups or categories that we can actually define scale into. We have business and finance, communication, games, knowledge, and many others. So if I go to a particular scale, it may be a sort of anagram scale. So anagrams, and you can see the author's name and the rating. Description about the skills, skill details. This is the rating, like, five-star rating system that we implemented during this GSOC itself. The ratings over time, feedback, and stuff, yeah. And we have the accounts Suzy web app also, which actually is concerned about the authentication in your login. And you can actually change your settings and stuff. This is for the accounts part. So yeah, coming to the main topic of the talk, so the current implementation after the integration. For the front end, we have used React.js, which is a front end library developed by open source by Facebook. And the main prime reason for using React was the ability to give, like, separate UI into several components. First was that, and the very fast and reliable UI DOM tree that it creates via diffing algorithm. And it creates a virtual DOM and stuff. And so basically, what happens is you can actually create UI components and then divide into, and it increases the reusability of your code. And also, it gives a very high performance as per stats. And main, like, redux, we have used. So redux is kind of a state management library, which we actually use for manipulating the data that comes from the server to the clients. So suppose if I speak about redux, suppose you have already you go on the login dialog box, and then you log in. And the response for the login, like API comes, that you are this user, and it identifies you as this user. Then the response, which comes, it is actually stored in the store on the client itself. And then you can, so basically it prevents any, so it actually manages all the data which is stored on the client like in running time. Material UI is for the theming and the UI looks of the part. And axios we have used for making network calls, like over HTTP. So why are we here like any clue? So we are here to learn about the integration of redux and how we went about it. So the question is why do we use redux? Why not like previously we had the flux architecture. Why did we go for redux and not flux? So the main reason is like there are five simple and very straightforward reasons. And it has been answered by Dan Abramov. So the first part is reducer composition. So in case of redux, we have a single source of truth that is a single store, which actually contains all the data. And there is no like, we don't have any dispatches between several individual stores, which we actually need in case of flux. So reducer, like it brings down all the complexities of managing multiple stores at a time. And it maintains a single source of truth. And the data flows from top to down. I suppose like if you have a root component, the data will actually be fed into the root component and it flow down to the basic level of UI. It may be as simple as a checkbox, as you can say. Server entering, so it also has the capability of server entering. But the issue with flux is, again, it comes back to handling the dispatches around multiple stores. And developer experience. So how many of you already know about redux and are having using redux? So redux already has the redux depth tools, as you all know, and it actually brings down the, like it makes a lot easier to debug and then actually see how it's actually working. And the ecosystem, it has a very vast ecosystem which has been developing the redux. The community is very strong. And it's very simple to use. You don't have any sort of complexity, as I talked about, and easier to understand. You can dispatch actions. And then all happens in a single store, which you can actually visualize in the redux store via the depth tools as well. So yeah, a directive structure and hierarchy, like I'll be talking about what directive structure are we following in our project? And the hierarchy, like how is it helping us? And how is it beneficial? So yeah, this is the source folder, like which contains all the main source code of a repository. And inside it, we have created a separate redux folder. So even if a new developer comes on day one, and if he wants to know where are actually all the redux files that has been created, so you can easily identify, yeah, that is redux, and I have to go inside it. So we have divisions sort of like actions, which actually has actions, different sort of actions. It may be related to maybe showing a snack bar, as simple as a snack bar, or maybe making an IPI call as well. We have action types, which actually defines all the action types that we require for the app to run. And we have the reducers. So these are the reducers. So if I talk about how redux works, if the app is simple, if it is based on the redux state itself, so it's very simple, like you all manipulate the state of the react component and then use it normally. But if we use redux, what happens is from our react components, we actually dispatch actions, redux actions which actually manipulate the redux store, which is maintained globally. So as soon as you call an action, the attribute regarding which data point you want to change it in the main redux store, and then it is passed down from top to bottom, as I said, and it is reflected in all the UI components. So this is how it works. So yeah, this is our main root component where we pass. So this is the provider redux provider, and we pass the store, as I mentioned. So we create a data structure or a store which is based on our project. What is our need for that? So I'll show you one of them. Yeah, if I see this default state, so this is the redux state, and this is the authentication part which we actually require only for managing the authentication part and just the login part of it. So similarly, we have for messages as well, like you interact with Susie, the response comes. So we handle, like we maintain it throughout the client, and similar for settings and other things as well. Yeah, coming back. So directive structure and hierarchy. So as I said, it is scalable. So as you could see, we have different files for each type of action. So if I want to create a new UI action, you go ahead and just add onto that UI action. But if you want to create a separate type of action entirely, you again go and create a file for that and again insert action into it. So if you go through the code base, it's very easy to actually add and then delete whatever action or reduce what you want to. So it's scalable, easy to maintain, and as I said, developer-friendly as you can actually see the Redux file separately integrated into this project as it was not done together. So as it was added later on, so it is actually taken care of that it actually reflects, like it's added differently. And you can easily see that. And middlewares and helper functions. So for the Redux integration, we have used Redux Promise Middleware as the main reason behind using Redux Promise was we have a very good sense when we use .then. So we actually know if we dispatch an action and if we use .then, developer, it's very easy to understand this will happen after the first step executes. So the main reason for that and also to actually make it asynchronous, that is the main prime reason to make the behavior asynchronous. And we have made Ajax Helper using Axios. I'll show that.