 Welcome to UPI Driven Development in Moodle. My name is Dhaval Bhargit and I work with the advisory team. Hello Moodlers, I hope you guys are doing well. Do you know how some people have difficult times working in the Moodle environment? We at Moodle Advisor are focused on solving this problem. We are the creators of one of the most popular themes in the Moodle ecosystem, that is Advisor everywhere. We have more than 5,000 happy customers and we get a lot of love from the Moodle community for developing this theme. At Advisor we have always been committed to open source development and our primary mission has been to improve the user interface and the user experience of all open source applications we deal with. With the same mission in mind, we created Advisor-MUI which has transformed the Moodle experience from this to this. Basically the theme enhances the user experience and at the same time provides partner interactions and ease of access. Our goal has always been to make Moodle more contemporary and we soon realize that this theme is just a part of it. We would apply the same principles in different sections in Moodle and while researching further, we came across grading. Grading in Moodle is cumbersome and time consuming. A teacher needs to go through at least three screens to grade one question of one user. We identified this as a major problem and we started looking on building solutions for this. We discussed this with our internal design and development team and came up with this design as a solution. As you see in this design, you can see all the questions of all the users in one screen. Also, the actual interface for grading and commenting on a particular question slides out from the bottom. This particular design can definitely act as a solution and while moving towards implementation, we encountered with a few hiccups. Our first approach was obviously to override the current grading interface. But we soon realized that this is not the way to go as it required multiple core level changes which eventually would lead to multiple dependencies. We realized that our primary hurdle was the current interface and if we could somehow bypass this interface to capture and store the required data, then our jobs would be much easier. We would simply build a new interface and render it independently of the current grading interface while directly talking to the database. But this was only possible using API. I've been talking about this API for some time now and before I go ahead, I would like to share some light on what it is. To give you an example, Google Maps and Uber. As you all know, Uber is a ride-hating platform and requires Google Maps as a primary functionality. What happens when you book a ride is Uber sends out information such as your start and end location and the time of the ride. And Google Maps responds back with the distance between the two locations, the average traffic during that time. And with this information and some parameters like number of rides present in that area, Uber comes up with a fare for you. Of course, Uber has been paying in millions to Google for using this service. But had they been thinking of developing this on their end, their investment would have been in billions for sure and the time required would have cost them this business. So now that you have a fair understanding of this API, let me tell you how, let me shed a little bit more light on when this API development is needed. One of the approaches is when we are connecting to disparate systems like Uber and Google. And the second is when overriding an existing functionality in a particular software being on the same platform does not give you the required access. So we had to basically use a modal API. So we use this in our grading software and with the help of the amazing modal API and some endpoints that we build on our end, we created Advisor RapidGrader, which is an amazing solution for grading and which cuts down the time into half. To understand a little bit more about how we did it on the technical end, let me invite Bharat Parik, who is a research guru and a tech lead on the Advisor product side. Bharat, over to you. Just a minute. Thank you, Dhaval. Hey friends, my name is Bharat Parik. I'm working with Advisor for the last five years and together we have created some awesome solutions like Advisor MUI, Advisor RapidGrader and Advisor course formats, which has around 1500 active users on the modal community. So first of all, I would like, I am very thankful to a modal community who have created such an awesome software which is feature rich as well as truly extendable. Now let's talk about our solution, how we use APIs in our base solution, but for that we need to know what is an API. So an API is nothing but interface which is used to connect two systems. So if we take an example of a food delivery app, you open that, you select the menu items from the menu and then you just click the order button. So what is happening here? Your mobile app works as a client, which sends the request to the server. In this case, the request will be your food items and the server will be restaurant. And in turn, server just takes the request and sends a message to you that the order is placed successfully. So that's how an API is used to connect two systems like, I mean, facilitate the functionality between them. In the current grading interface, there were some challenges. We could not, we could not modify the current page in any way. We could not modify the HTML output like any other pages in Moodle. So that's where we turn to the Moodle APIs and it was a really great decision for us. So using Moodle API and the JavaScript solutions, we have created this interface which provides easy access to the grader, students being graded, easy access to navigate between the questions without changing the tabs or pages in the system itself. But how did we develop it? So for that, we need to know how Moodle API works. Moving on to the next slide. So API development in Moodle is consisting of three parts. First is external service description. Think it off like a file where we need to register all our APIs. The second part is external functions. In external functions, we create our API endpoints. All the endpoints which are needed in the plugin or your API gateway. And the third part is actual API call where you call the API endpoint and you will get the response. Just like the food delivery app where you are just ordering the food and getting a response that your order is successfully. If you want to know more about it, then there are some documentation link on Moodle which is in the bottom left corner. You can have a look at them. So let's talk about the first part in detail. All the API endpoints are registered in the DB folder of services.php file in a Moodle plugin. So you will have to create a DB folder and then create a services.php file in Moodle using which you can register all your endpoints. So here you can see that we have created and registered a function named get quiz questions. So this function is used to get all the questions for a quiz. This was the first part. Now we will have to define actual endpoints for the system. External functions. So to create API endpoints in Moodle, we will have to create external functions. External functions are stored in external lib.php file, this in a Moodle plugin. And all these functions can be accessed by API clients like your mobile app or the web services API of Moodle. So using this, we can connect, we can create a different interface and use Moodle's APIs to popular data there. Now this, the external functions part is divided in three parts. First is we have to define three functions. First is a returns function. Where we define which parameters we have to give to the API endpoint. So suppose you have to get questions of a quiz. Then obviously you will need a quiz ID or the attempt ID for that. So here in this function we have to define all those parameters like we are defining here. We are defining number, the question number and the question status. The second part is where all the business logic resides. So in the second part, the second function, we write all the code. So suppose in the case of quizzes, we will write a code for getting all the questions for the quizzes. Suppose we are writing an endpoint for logging in users. Then in that function, we will write code for the actual login. And the third part here is the response function. In the response function, we have to define the structure of a function. In case of get quiz question function, we are returning the number of questions, the question title and the question ID. So our response function should give all the structure of those. Because if the response function differs from the structure function, then there will be a fatal error in Moodle. So we have to define all those properly. Now using all the external function and the external service description, we discussed in the previous slide, we will get a single URL. So this is an API endpoint. So API endpoint is nothing but a URL as you can see. You can open this URL in your browser and you will get all the results. So in our case, we will get all the questions for a quiz. But now suppose this is a URL and someone shared it with every person. I mean person who you do not want to intend the data to be shared. In this case, if they open this URL, they will get all the data of your quiz. So how to limit that? How to limit who will have access to the data? For this, we have a parameter security token in Moodle. Using this, we can limit the access to the API. So only the persons who has access to the security tokens will have access to the API endpoint's data. But that is not all. You have to take care of some precautions while creating an endpoint. You have to monitor some system resources. So these are some points I want to discuss about. First is security. Every API endpoint you create should be secure enough and should not have access to the malicious users. So for that, we can have user names, passwords for securing the API. For example, we can take an example of WhatsApp for now. WhatsApp is an API client which connects to the WhatsApp servers for transmitting your messages and receiving the messages from other users. So suppose there is no security aspect there. The malicious users will be able to access the messages you are sending and you are receiving easily. However, that security is actually necessary for every API endpoint you are creating. The second part is system monitoring. So this is again the main part while creating an API gateway. Again, let's take an example of WhatsApp. You send a message to the message to anyone and instantly the message is sent to the recipient. What if you are sending the message and it is taking like 5 to 10 minutes for sending a single message? Obviously, disrupt the flow. So for this, we need to monitor our system. If there are some system resources being not used properly or CPU usage is high or there is system load on the server. So in all these cases, we need to monitor our system and make a pattern of all the system loads. So in future, we can manage our system and it works in its full efficiency. So this is from my part. If you have some questions, then you can obviously connect to me on my email ID for clarification. So Dhaval, over to you. Can I go to the next slide please? Yes, sure. You will have to manage that. Thank you everyone for listening to us very patiently. We have a small quiz for you. I am going to paste that URL over here. So that it helps you to understand the small quiz so that you can take and understand what we have explained a little bit better. And when you give this quiz, you stand a chance to win some amazing advisory products. That's it from our end guys. We are open to any questions that you have. Thank you very much for your brilliant presentation. We have five minutes still. So please send your questions here on the chat so guys can reply that. Someone in the chat before was asking about what an API stands for. So API basically stands for application programming interface. It is basically one single interface or it stands like a bridge to connect two different softwares. So as you know Uber and Google Maps both are independently developed and they do not have anything in common. But when you want to interact with each other, both have. And that's how they communicate. So this API is basically a bridge between two different softwares. So Rajnish is asking if we are using React for frontend. But no, actually we have used a plain JavaScript for this and use Moodle's templating engine for all the interface design for now. But yeah, this can be converted to a React interface or Angular for that matter. So Moodle is asking how Moodle is different from its counterparts as for a system security and reliability issue. So Moodle, I'm working with Moodle for a long time now. So there are security measures in place for everything like suppose a user being logged in, cross-site scripting attacks and form validations. So for each of those things they are security measures at place as well as Moodle provides an API for connecting to the database also. So it is the best practice to not write the code for connecting the database. You should always use the APIs provided by Moodle for even connecting to database or connecting to APIs and etc. So this way you have advantage of layer of security provided by Moodle. And again there is a security overview page in Moodle where you can see all the precautions you should take for your specific server.