 So we have the next speaker here. It's Abhinav here, also like a long-term member already of the project. He has been a Google Summer of Code student. And Abhinav, what's your background? So basically, I'm a computer science undergraduate right now, and I'm really into web development. And currently, I'm exploring backend. Like, I've worked on front-end for the past two years, and now I'm dabbing into using Flask and other backend Django and other frameworks for the front-end project. Yeah, mentoring students in Google Summer of Code, which is upcoming soon, one of our coding programs here with OpenEvent. And where are you from? Which city and which university? OK, I'm from the Indian Institute of Information Technology, Alabad. And originally, I live in Bhopal, but in India. But currently, since I'm in the university, I'm staying in Alabad. OK, thank you very much. And you were talking about NBJS, how it empowers OpenEvent front-end, a round of applause. So Dilpreet and Shubham, they discussed, like, you guys are aware by now that we are using NBJS. I'm going to delve into a little deeper into why exactly we chose NBJS and how it is benefiting the project in the long term. And what short-term compromises we made, but which will ultimately result in a better open-source environment for the users. So as you said, NBJS is basically normal MVC framework model view controller. But there are certain aspects which sort of differentiate it from the other MVC frameworks. And as you said, the major reason we chose to go ahead was its compatibility with JSON API schema, and how is it serving a purpose that you'll see. So the whole idea behind AMBER is a convention over configuration. And that is a commonly used term, but people don't really get exactly what they are getting out of using those conventions. Conventions means more time to do what you would have done, but are we getting the output we expected by diving into these conventions? So this is a minimal representation of how exactly things work around in AMBER. And this is true for mostly all of the MVC frameworks. So in AMBER, the key point is data around an action surf. This also was discussed by Dilpreet. And he has already discussed the things regarding data in detail. So as to why we should be following this approach, actions are what does it get, what it means to us. The general idea is that you don't want the data to be stored in a central place so that each time you have to, at a lower level in your code, you want to use that data. You don't want to make separate calls for that. Each time it is being loaded. On the other hand, the actions. You want the logic to be in a single place. So if there are four components in a single template and each of them have four actions, instead of having four files in which you will write those four actions, you want them to be in a single logical place where you are controlling the entire logic of the application, hence the action support. So he included almost all the components present inside AMBER. And services is actually a major part of it. It was not in this list, so I added it. So services basically, service is a long-term AMBER object. It is active as long as you are running the application. It doesn't matter which page, which route you are on. Once you are into the service, the service will exist. And the login part, the form validations part, all of these are being handled by the services. So the biggest advantage of doing it this way is that, let's say there are 50 forms in the entire project. And each of them will have several validations. And I need that, OK, the validations can be different. Like this is an email field. And there might be a password field. So we'll decide the logic according to them. But the basic functioning, that when you are not satisfying the requirement of the validation, how the text field should turn red, how the form should stop, how a model should pop up to stop you from submitting the form, citing the error, these are common. The code for this is common. The general idea is common. What to do when a validation fails. So services take care of those kind of things. So there is a form service number, which manages it pretty well. So the output, like OpenEvent was working fine, is working fine. This event here, like the anti-fossage submitters being hosted on the legacy code. But the thing is that legacy code was made on the go. And different people contributed to it. And as of this moment, the code got really scattered. The back end is completely coupled with the front end. And there's a lot of inline CSS, a lot of styling flaws, a lot of design flaws in that, how the code is structured. And for a new beginner, it's really difficult to just start contributing to it. And that's when this idea was born, as Saptak told in his talk, how, why we need to decouple the back end and front end. So after following all those conventions, this is the kind of difference we achieved. Like these are, this code is for the same file, the same exact file. And look at the difference in the clarity of the two. On the front end, the template is a template. And on the back end, the JavaScript code is there, the handlebar tags are there, the styling is there. And as I'll cover later, along with using AmberJS for the UI part, OpenEvent front end uses semantic UI. And that is a really robust framework for UI things. And the best part is that, I'll come back to it, the semantic UI part. So take this, for example, how conventions benefit us in the project. As we define a module, as we covered in the talk. So in the module, this is a module for an event. And an event is related to a session. So our event has many sessions. And a session belongs to an event. So the only thing I did was mention these two things. And this get request that the URLs would be event slash event ID slash sessions. I didn't have to manually specify. And this was the key thing responsible for us choosing AmberJS. Because the entire OpenEvent is based on routes, there are a lot of routes. And the complexity of the routes is not that much. Because they are logical relationships that event will have many sessions. Sessions will have a venue. So the logical relationship was there. And by using Amber, we were able to skip the manual labor of actually coding, hard coding those routes. Like, I don't need to specify these routes because the API follows the JSON API schema. And Amber has a JSON API adapter. So all I have to do is specify the relationships. Like, an event has many sessions. A session belongs to an event. And it will automatically generate the URL according to the JSON API schema. And this code is stable for long terms. Even if the API specification changes, all we will have to do is change the adapter. Not the entire front end. Or in the templates, there's not a single line which correlates to how the backend is supposed to work. And then the best part about JSON API was that it is highly efficient. For instance, I want a list of events with several filters. Let's say they should belong to a particular track. And on top of that, they should be within this location. So the filtering is being handled on the backend and not on the front end. Like, it's not like I fetch a list of 100 events, then filter them according to my needs, and then display them like it is done for most of the Angular and other frameworks, like how it's done over there. And what Amber makes it easy is specifying those filter queries. Like, if you look at them closely, all the filter queries, this is a request for events. So I request that I want to query events, and then I include these things. Like, they won't be included by default. Whatever I include in the include clause, they get included, and they are fetched along with the event. So you can use them. Like, if I import events as event, then I can just use event.tickets, and I will get the list of the events tickets. And if I don't use this include clause, the tickets won't be fetched at all. So the scalability is there. Like, when the app scale, and when there are instead of 100, there are 10,000 events, this will actually matter in terms of how long the network requests take. Similarly, like, there is page size. The pagination is handled on the back end side as well. We don't have to worry about it. And like, that was the whole point. Like, the fetching, how we are able to fetch the data without actually hard coding the URLs and the efficient data usage that makes AMBER worthwhile for this project. Then the thing with semantic UI is that it's an independent robust UI framework. But for certain JavaScript frameworks, it offers special integrations. For instance, for Meteor, there is semantic UI Meteor. For AMBER, there is semantic UI AMBER. And that reduces the code. Like, that increases the code efficiency even more. Because when we are using an integration with like, it's integration with semantic UI, I don't have to worry about typing the JavaScript side of the semantic UI components. Like, if there is a pop-up, there will be definitely some JavaScript code. If I'm using the integration, I don't have to worry about it. These braces are enough for that. Like, I just opened a curly brace. It's pop-up. I specify what options should be there, and that is done. And the next slide there will be comparison. Yeah, so here. Like, that code, that is three pop-ups right there. And all three pop-ups are doing three different things. And if I were not using it with its AMBER integration, I was using normal semantic UI, these two combined will make the code for a single pop-up. So, like, it was really, really well, it's pretty compatible with AMBER. And in general also, it's very responsive. And it has gotten great community support recently, in semantic UI. And that's why we went ahead with semantic UI. So, like, this seems like a good page. It's looking pretty great. It's completely responsive. That's some wire stream shot. There are colors. Everything is padded. And the best part, like, generating this page, didn't require a single line of CSS from our part. There's not a single line of CSS in this code. It's completely being handled by its default classes available in semantic UI. And, like, that is really efficient. If you're able to generate something like this without actually dabbing into CSS at all. And that's, and the code looks much cleaner because of that. You can make any adjustments you want. And what we have, like, as a best practice, what we have tried to incorporate is that in the open-event front-end project, we usually don't prefer any styling, like, any extra styling to be applied. The default classes are enough for our needs. Then, since AMBA uses components, there is a potential for, like, extreme cases of code reusability. These cards, like, this is the landing page of open-event. And the events have been explained in cards. This other page is on the explore route. It helps you search events, according to your categories or search query. And this is the sessions route. And they use three different versions of the same component. And the code is entirely the same. All I'm doing is changing what I'm passing into the component and some if-else manipulations. So the size of the code base has been reduced exponentially in terms from migrating from the previous implementation. This is the code for the entire three pages. I only change what I pass in the module. And it adjusts accordingly. Then AMBA has a powerful CLI, so you don't have to worry about boilerplate codes. Like, if you want to generate a component, all you write is AMBAG component and the component name. And the components get generated along with its test files. So you just have to validate it. Testing on AMBA is really easy. Like, I saw a booth of UL issues down in the event hall. And AMBA sort of incorporates by that logic only. Like, if you see, it says, visit this URL. And then you visit the URL. You can assert if the current URL is equal. Like, this is a very simple test which checks that if the user is logged in, then which URL should be there? If the user is not logged in, what should happen? And this test sort of confirms it. So there are acceptance tests. There are unit tests. You can write them custom. boilerplate code is there for the unit test. So testing is pretty easy. So right from the day one when we started coding on this project, we were encouraged to write tests. And we did write tests for all the components. The documentation for AMBA is excellent. Because all you have to do to get started with AMBA is go to the official AMBA website. There's an app which you can make. And that pretty much covers everything related to AMBA, including AMBA data. The community of AMBA is very active. For instance, anything we needed, which was not available by default in AMBA, add-on for it did exist. Like, all we had to do was a simple Google search. Stata requirements. And there are thousands of open source developers who have readily made components for us. For instance, like, scheduler is still pending to be implemented on the front end. And scheduler is something which requires extensive code coverage. And combined with the complexity of writing it in AMBA conventions, it might become a GSOC project of its own, if some were to write it from scratch. And hence the mentors and it was decided that we are going to use an add-on. And it was readily available in an open source. AMBA, CRI schedule. There are thousands of add-ons for AMBA and they are being actively maintained. So lastly, I'll conclude by specifying some areas that you can work on right now. Like, if you're writing a proposal for GSOC or if you're just interested in contributing in general, these are the areas which are inactive development as of this moment. All of those. Fact, API integration is a great beginning point for anyone who wants to contribute to the project because all the APIs sort of follow the same way, same structure that is implemented. So thank you. Many questions. Thank you very much.