 My name is Abhishek Sabalkar. I am from the IITBX team and I would like to introduce my team members, Mr. Alkam Sheikh and Saurabh Sahu. So we are here to present to you to the topic integration using APIs inside IITBX platform. So first of all, I'd like to brief you about the IITBX platform. IITBX is an online platform which provides massive open online courses and it is basically based upon Open edX software. So now I'd like to introduce you to the aim of the project. The aim is to explore microservices with APIs as the method of integrating IITBX platform with any other software. So now we look at the structural overview of the project. At the center we have the control section and it works with the different APIs used which are the course API, course import API, grade API and platform API. And these APIs are used to manage and control the various instances that we create using the IITBX platform. So here we have as an example the Madras server, Bombay server, Delhi server and Kharagpur servers. So the platform API is used to create these instances also known as the platforms across the country on different local organizations. And the course API is used to create courses on various of these platforms. The course import API is used to import one course from one platform to any other platform needed using GitHub as the intermediary process. Then the grade API is used to simply query the students' grades on any of these platforms. We can also see that each of these platforms also has a local database containing the grades and courses of that local server. So now we look at the architecture of a project. There are mainly two components, control section and the IITBX API. The control section is used to interact with the user on the front end. Well, the IITBX API consists of the various courses, various APIs which also have their local databases. And these function together to provide the backend services of IITBX platform. So the course and platform API databases are interconnected using the group member database. The grade API has two types of databases, namely MySQL and MongoDB. Well, the course import has a reported database. Now these are the components that we've worked and completed in the duration of the seven weeks. You can see control section, the various APIs and also securing these APIs using OAuth protocol. So first of all, I'd like to give a closer look on the control section. So what is the control section? The control section is the central hub for managing various services provided by the IITBX platform on the backend. It acts as the, and what does it offer? It offers a front end dashboard, which is user interactive. And what is its purpose? Its purpose is to interface and act, interface with the backend IITBX APIs. And it also acts as the client Django application to access these APIs. So this is a snapshot of the course creation form in which we enter the details of the course. And when we submit these details, we have actually used Django forms. And when we submit these details, they are posted back to the course API, which records them and also gives a status code accordingly if it's successful or not. Similarly, we have a platform creation form and other creation forms as well. So now I'd like to introduce you to the APIs that we developed. First of all is the course API. So basically what is a course? A course is a collective set of study material provided by a user to its front end user, which is tailor made for the front end user. And what does the course API do then? It acts as a service provider for the courses hosted on the IITBX platform. And why is it necessary? It is necessary because it allows us to interact with the database without having intricate details, knowing about the intricate details of the database, like which software does it follow, like MySQL or MongoDB. We can just not worry about that and use the front end software as we need. Then the course API internally consists of two main functions, the get and post. Get is for retrieving the courses on the platforms. Post is to create new courses on any of the platforms. Now we have also used the serializer known as the course overview serializer. The serializer basically is a component which is used to convert the data in the request format to the Django workable format so that we can work on it and process the data and also give back the response as needed. So these are the functionalities. First of all is the course creation. We can create course by posting at the course API in the JSON format. We can also retrieve the details of a particular course on any of the platforms using course key of that platform. We can also retrieve all the courses from the platforms. And also we can find out which platforms are particular course like CS101 on which platforms does it exist on in the whole environment. So now I'll give you a closer look at the platform API. So what is the platform basically? A platform is a base for an organization or it acts as a server to host all the resources allocated to it by the ITBX platform. So what does it do? It provides us interaction with the database same as the course API. And why do we use it also? We use it to decouple the front end and back end as I said before. It also consists of two main functions get and post. Get is to retrieve the platform details and post is to create new platforms on various locations and the serializer uses integrated platform serializer. The functionalities are the same, almost same as the course API platform creation. We can retrieve the details of one platform, retrieve the details of all platforms or the courses that a particular platform has. Now I'd like to talk about the interaction between course and platform. So what kind of relations should exist? The relation that should exist is many to many because one course can exist on multiple platforms as needed by the author. Well, the platform also has to contain many courses according to the needs of the students. So now I'd like to call Saurabh to continue with the presentation. Good morning, everyone. Myself Saurabh Sahu and I'm here to take the presentation further. So the part that I'm going to explain is course import. So first, what is course import? The course import is basically transferring one course which is already present in a platform into the other platform. It is called, it is course import. Now why course import? Suppose in a platform we have a course and now we want that course to be present into the other platform. So we are not going to create that course into the other platform. So what we will do, if we want that course to be transferred into more than one platform, so we will use course import API. It will transfer that course into the different platforms. So basically course import has three main modules. First is course import API. The second is cloning that course from ITBX server into the remote system using GitPython and third is inserting course into the MongoDB using PyMongo. So this is basically the block structure of my course import API. It has a database which has attribute course directory and status. It has function, get function and post function and it uses database dbsculite3. These are the functionalities that are provided by the course import API. So basically as I explained earlier, course import API imports an existing course from one platform into the other platform. And to manage this functionality, we need a backend API which is course import API. What course import API delivers? Using post and get function, we retrieve the data which is already present in the database of course import API and using post function, we insert the data. What is the data? It's the course name that we are importing and the directory where we are cloning that data and it has another attribute status which shows that whether that course has been cloned or not. This is the representation how get function looks in the API. Here we can see the ID, course, directory and status. The course that we are importing from one platform into the other platform directly is where we are cloning that data into the control section system and status shows whether that course has been cloned into the system or not. So as I said, my course import API has three modules. First is the course import API. Second one is cloning that data from GitHub into the control section system and third is transferring that course into the Mongo database of the IITBX platform or the IITBX platform. So here status shows that course has been cloned into the directory of control section. This is the post function. It shows that using post function directly, we can insert the course name and directory and it will be cloned into the directory of the control section system. The second module is cloning course from IITBX server into the remote system using Git Python. We all know about the GitHub. GitHub is a version control system that detects the changes or modification in a file and coordinates that changes and modification into the other user files which are accessing the same repository. Yes, and now explaining a brief about the Git Python. Git Python is a Python-based library that communicates with the Git repository. It provides abstraction of Git objects for easy access to the Git repository either by using pure Python program or Git command implementations. So here the second point says that initiate Git.repo in the destination directory. What it does, we all know that when we clone a repository, it consists of a .git file which shows that the repository that we cloned is an authorized copy of requested repository and not a copy made illegally somewhere else. So we import Git and specifically class a repo from the Git library which creates that .git file and using other Git Python functionalities, we first fetch that repository and we clone it into the directory. The third module is inserting course into the MongoDB using PyMongo. So PyMongo. PyMongo is a Python distribution containing tools for working with MongoDB. So PyMongo was created to incorporate the functionality of Python as a programming language in MongoDB as a database. So here what we do in each platform, the database is named edxapp which has collection named as model store, model store dot active version, model store dot definition and those all collections have different syntaxes. So the content of the cloned courses has to be passed as an argument to the post function which will store the content of that course into the edxapp database. So it will show that the new course has been created into the IITBX platform of the other server. So here we'll use PyMongo to access the database, pass the course of that course file and as an argument into the module and insert that module into the collection of database. So thus when post request is sent to the API with the course name and directory name where we wanted repository to be cloned, API first clones that course from IITBX GitHub and then insert that course into the MongoDB. Now I'd like to call my friend, Arkam to take the presentation further. My name is Arkam and I'll be discussing about the grade API and how we can secure all the APIs developed so far. So what is grade API? Basically it gets the grades of a student depending upon the query made by the user. So the basic we know that control section it is a user interface and there we have our interface for grades. So from that the API is called. The API is called. The API depending upon the query connects with the platform. So the platform can be a server in Madras or Bombay and the server fetches the grades in the database and then returns the query grades to the API back which returns it to the control section. Major four functionalities developed here are getting grades for all the courses on a platform, getting grades for a particular platform for all courses and for all students, getting grades for all students for a course and getting grades of a particular student. So these are the outputs. So basically this is for all platforms. So here you can see there's like two lists and there's like documents inside that. So the outer list represents the list of all queries made for a platform. So one element of that is a list for a platform and that list is for all courses. So I hope you got that. Like in the second one you can see this is for one platform. So this is the entry which is in the inner list. So if I give the platform, the API knows which IP address to connect. So it connects to that IP address and gets the grades. So the other one is now I give the platform as well as the course ID. So it gets the grades of all the students for that course. And the last one is I also give the student ID. So for a particular student, it gets the grades. Now we have all the APIs here, but the APIs are not secure. You know that the rest APIs are hosted on some server, but now anybody can make call requests and just get the data. So we need to secure the APIs here. So for that, we can use some protocol. So our standard protocol used for this is OR2 with a layer of OpenID Connect. So we tried using key cloak and open source service provider for this. Like we tried many open source service providers, but this is the one like we integrated the most using key cloak. So I'll talk about what first then we'll move on. So I guess the bell has run. So what basically is a protocol where you use some methodology with access tokens to allow authentication as well as authorization. So authentication, you all might be knowing what is authentication. And authorization is like providing some privileges to some web app or application. Like you might have encountered this so and so app wants to access your Google accounts. So this is authorization. You are allowing it some privileges for other app to access your other apps like data. So I hope I could explain this, but there's no more time. So I think this is the flow for authentication and future scope. So what the future scopes are here is that we are like, we made the grade API, but it's not time efficient because the database structure, like if I go in the detail, it's like a tree sort of structure. And we know the object ID for the last layer. So if I come from the root of the tree, I think I have to traverse the whole tree. Each time a query request is made. So I'm traversing a lot of data just for getting a single query or like two, three documents. So it's not time efficient. And second thing is the key clock thing we tried. We tried integrating it with the APIs, but the, yeah. Yeah, you can see the last step. Like we were able to integrate all of the step, but the last step of exchanging the access token, we weren't able to figure it out because the key clock isn't like I already do it in open source, but the documentation is not so good. So we haven't figured out like how to do the exchange token part. We have got the token, but it's not working currently. Yeah, and last thing is the on a particular platform, you have all like many courses. So when you select a platform, there's a Ajax request made to get the courses on that platform. So this Ajax form is currently not secured. One of the reasons being we made the API separately and then integrated with the ITBX platform at the end. So we didn't have any authentication beforehand. So the other thing which can be done is securing those Ajax forms. And thank you. What is the motivation for doing this? Motivation for doing this. Learning. No, no, no, no. Means like why such a disparate system? What? Such a disparate system. They should know their motivation, right? Motivation is not only to get a certificate, I believe. For coming to IIT, but the idea for the project was you are aware of that your distributable IIT Bombay X, whatever activity is being taken up. So the idea is to have multiple IIT Bombay instances all across the country. Maybe something like 500 instances running parallely. Now supposing that we have based on IIT's experience, we have a bunch of courses and every college is running a platform, but those courses are only on IIT Bombay X servers. So how do you share with them? So one option was IIT Bombay X export import. But then you are expecting that people at the various colleges would know a lot of things about the IIT Bombay X platform. So here what we have tried to do is give a central sort of like a control station from where you can manage the various... I think this did not come into your... Yeah, because... Central theme. Central theme is very important, right? Bombay server, Madras server. Yeah. So what is that? Those are all IIT Bombay X? Yes. Yes. Okay. But you are not telling them to import, export all of that, but from the control station you are managing the courses. Which courses will go there? Yeah, so supposing CS101 you put on Github repository. So with the help of these APIs you will just be able to import the course just by anybody who is just a user of the platform without having to know Github, without having to know export, import or the commands for creating a course. Independently if they want they can create new courses. Certainly they can. Like local to their college they can. This is just one step ahead which we are going and... Yes, yes. So there was one thing which I saw was creating a platform. What does it mean? That is to add a platform. Supposing that... So you want to spawn a platform? Yes, because by spawning not like installing it, installation is done. But you want to add that as part of this entire program where you would want to share a course with them also, let's say. Somebody is running one... Oh, adding that in the platform. IIT BombEx in Jharsubhuda. Already a platform exists. Independently no problem. But supposing they want to be part of this program and we would like to share courses with them. If we share then we would want to know what the grades are for each of the students. No, now you have one problem here. That is somebody is running on Ficus and somebody else is running on Hawthorne or Ironwood. Yeah, so that will be... First of all it will not be a problem. I think there's another project they have migrated database. No, no, no. Not that, not that. So grade related data because it has been there since the very first version. That has not changed, it will not change because that is the core of the platform. Additionally, new things get added but it doesn't impact this first thing. Secondly, control section will be managed by somebody who is aware of the various IIT BombEx instances running all across the country. So even if there are changes then it is up to the API provider which I will, let's say, IIT BombEx API provider they will have to manage the differences between the various versions. So control section, so IIT, so like for example Madras server, is there a person from the Madras, IIT Madras who will have a user ID on the control section? On the control section. So he can browse, he can push courses here and there. Exactly like how blended MOOC where there were various separate roles, institute coordinator. Similarly, you could have a coordinator, a platform coordinator for Madras who will have a role in the central platform. So how do I get access to the control center? I'll have to contact IIT BombEx. Yeah, so that roles we have not implemented right now but yeah, whoever is managing the program will have to assign roles to the various centers. So if I want to become a center, then I have to contact IIT BombEx offline then get an account and then correct. Correct. So now here GitHub, you are actually exporting the course from one place and then pushing it on to GitHub. Whenever a new course is created, it is like pushed to the GitHub so that if another platform wants to... Oh it is already, so you have just one link. You're not doing every time. Yes sir. You have one link, right? So whenever a course is created, you assume that everything exists on GitHub. No sir. When we create a course, then after creating that course as a repository, we will like push that course into the GitHub. Okay. And if another platform wants to import that course. Yes. No, no, before that I have a problem. That is, we are going to push it to GitHub. So he makes another slight changes. He removes a video. What happens to your system? Sir. How are you handling that? Sir, if ma'am wants to delete a video or like... So she has already created on the... Somewhere in between, she modifies something. Now what do you do? Yeah. So have you handled that? That is what I am asking. Okay. No sir, this scenario is not handled. Whether you have handled... Okay, not handled. Not handled. The assumption again you can say is that... Have you heard... Have you thought... Courses finalized when you put it on? Yeah, have you thought about such problems? Which are very important when you say distributed? Yes sir. I think... Sir, if I want to push it to GitHub again, I can do. So that would... Yes, but what I am saying is when you are ready to distribute the course, that's when you will say that okay, now go ahead and create the course, right? And then that means you have completed the course. It is not... But of course it can be implemented if that is a requirement, but currently it is not. Actually it's a good idea. Because I can see if rather than providing an IIT Bombay X to somebody, we can actually make applications like Web App for particular college or school. They can simply import the courses and give it to there, rather than having IIT Bombay X, means the big system. They can have simply an application where they can browse through the courses. We can provide Windows applications, mobile applications. Is it possible with the system? No, as of now we have assumed all are IIT Bombay X. No, but let us say if data is there in GitHub, it's in some form, textual format, correct? Yes. So video links are there, title information is written there. Yes. So by taking that MongoDB schema, can we create an application which read that and present the course? Certainly. Yes. So if it is possible, so I think that this problem, distributed version of IIT Bombay X, we can think it from a different perspective. Grading is a little problem, but if we work on that, see it's one month work, we can think in that way also.