 Okay, it's always running. Good. So our next speaker is Shupan Badia, who has been a great supporter of the project for a long time, involved as a developer, involved in many different layers, also helped just like SubTag to deploy the project here and run Eventier, so we have a great system here to use at the first Azure Summit. And maybe know before you start what's your background, where you are from, and like from India, apparently, but whereabouts in India, with the university and so on, what's your background? I'm from Rajkot, Gujarat, in India, and I study at TripleIT, Alabad, that's in the east of India. Actually, you have your microphone for yourself. So yeah, thank you very much, and you talk us about convention over configuration of the event in JSON API. Thank you very much, and here are you. Good morning, everybody. I'll be mainly talking about... One, two, three, John. Test, test, test, yeah. So I'll be mainly talking about why we use the JSON API spec. Myself, Shubham, I did GSoc last summer with FOSS Asia under the open event project. I was also a GCM mentor for FOSS Asia last year, and I was one of the grand prize winner of Code Heat conducted last year. So as Saptak described, the API we had in the old system had some basic functionalities like the basic authentication, role-based control. Role-based control, like admins, organizer, co-organizers, and the basic route operations. So although we had an API, we went using it in the front end to make requests and retrieve data. The API was actually built separately as a way for third party applications to plug in into open event and fetch the data. So as it was not well used in the first iteration, the API was not very well developed. Only a few accrued operations were there and all the information was not available. We used the SwaggerDocs for displaying the documentation. Although SwaggerDocs generally follow the open API specification, we didn't adhere to any structure at all. So it was just some JSON structure responses at that time. So what we first needed was proper relationship definitions. We started looking out for API specification and the first thing was because we have a lot of roles. Like you have an organizer, co-organizer, track moderator, registrar, and each track has multiple sessions. Each room has multiple sessions. So there are a lot of relationships. And it becomes quite convoluted to code it in via a regular JSON framework. Another thing we wanted built in was sorting, filtering, and pagination. So JSON API. So JSON API is a specification for how the client should request the resources and how the server should respond. It minimizes the number of requests and gives a focus on caching the data so that you don't have to regularly keep making requests to the server. Why JSON API? JSON API follows the convention over configuration ideology. A convention over configuration means there's a convention at place which you have to follow. There's no other option. You cannot configure things, but that doesn't mean that you lose the flexibility of the API. It reduces the number of choices a developer has to make and eases the collaboration in a team. See, a falsity of projects usually have a large number of contributors. We participate in GCI, GSOC, and students come, contribute for a month or two, sometimes maybe more, and they go back. So we need to make sure that all the API written follows a certain specification. It's hard to collaborate if we're following a random structure without adhering to any specification. One of the major advantages of JSON API are compound documents. So it allows related resources to be included alongside the HDP request. So in a normal API, if you're requesting a track data, so you only get that track only. But with JSON API, you can include these sessions related to the track, and you can also page in at that. So only a number of, say, first five sessions will be included in the track. It could decrease the number of necessary STTP requests. For example, if you have a post management system, so your post can include the author object. So the author's user profile will be included along with the post, as far as field sets. So we have, actually, for any normal event, we have 25 to 30 fields for a single event. If you fill out the whole form, we have 25 to 30 fields. And the front end may not need them all at some point of time. So you can specify which fields to include by that type, like fields, articles, equals to title. So only the title will come, and the body will come. Nothing else will come. This is a normal JSON API response. There's every JSON API response has a data JSON object in the root, and this one is when we include an object. So there's this article, and the included author, who has the type people, the ID, and their attributes. So with a single request, I can fetch the author, and there's much less request overhead. This is the example of pagination. So there are lots of articles in the event management system. Then the links of the current article that you're retrieving, the first of that collection, and the previous and the next will be displayed along with that. The document must contain one of these three, the data, if errors, if any present, and the meta part. If, yeah. Handphone right now. Okay. Okay. No, no, they're previous. So it doesn't overlap the cable, okay? No, I understand. Satyak, are you okay? No, I'm okay. We just cut this out of the video. Maybe we should hit somebody who shouldn't overlap the cables because they're different receivers. Okay, sure. So I'll be continuing with the document structure. If there's any error, the error is also a JSON object, and an error response should not have a data root in that response. The document may contain one of the following. JSON API root that describes which version of the API using like v1, v2, v3, you can define it on your own. The links that are used in pagination, the self, previous, next, last, and first. Included mentions the included related object that you've used. This is one other example of the JSON API response. So what do we use to display this JSON API into the documentation? So API Blueprint is an API. API Description Language for JSON API specifically. This is an example of our generated documentation. We use AG-LIO for rendering the API Blueprint file. It's a single file and you mention all the fields and the type of the data that they should have like integer, string, and here is the description of the user's API. So we first mention what the API does, what all fields are there, and then as you can see here, all the methods of the API will be listed like list all users, create users, get the rates. All this is auto generated on every Travis build that we make. You can also check a simple request and a response via the show hide button that AG-LIO provides with itself. So an API is only good as a documentation. If you don't document what your API is doing, it's of no use because our API is a public one. It's mainly dependent on that. So how do we check if the API follows the standard that we have mentioned? To check if the API follows the standard and the API is updated with every pull request. So if you make a new pull request and if you don't include the documentation, the build will fail and it'll tell you to add the documentation for that. If you change anything in an existing API in the response structure, the build for that pull request will also fail and it'll tell you to include the change in your documentation. So our documentation is always updated. So Dread is a command line tool for validating the API blueprint document against our backend implementation. So how does Dread work? So Dread basically runs the application. Ours is a Flask application. It runs the application and it starts making the request mentioned in the API blueprint file one by one to the server. Whatever response it gets, it checks the validation, whether it's compliant to the GSE and APS specification or not. If it's compliant with the GSE and APS specification, the next step it checks whether it complies with the existing written documentation. So this is a pull request for that feature. We've used Flask with JSON API to as a framework for the JSON API specification. So what we wanted, one of the thing that was there that our data table architecture and the response that we give may vary a great deal. We wanted a framework which doesn't need to be coded that much in a sense that you mention the fields matching the table and you can have an API ready a post API ready and all the API ready for that. After you mentioned that post and get specification, you can link it to the existing function we already had for working on the post data or the delete request and the raw. We didn't want to expose all attributes of table. Some attributes were internal. We wanted to compute additional attributes like non-existing attributes too. We have a statistics API which tells you how many events are in the whole system, how many tracks are there, how many tracks have been accepted, rejected and how many speakers have been accepted, rejected. All of that which is public can be available and other can be available via the JWT authentication for the admin users. It also enables us to create a resource that uses data from multiple data storage. So right now we do have a single DB but we may in future we may be using multiple database and moving to more service oriented architecture. So this helps in complying with that. Flask raise JSON API as Saptak explained in the diagram in the previous presentation it's a crude interface between the resource manager and your data. So the basic functionality like deleting a resource. I don't need to write any code for that if I'm not doing anything additional then deleting the resource. So I mentioned the fields that are required and based on that ID the field will be deleted. We have some permission which we specify along with this specification to make sure that a non-authorized user doesn't delete any data he or she is not supposed to access. So that's all for this JSON API specification. Any questions? How many of your APIs are just data access players and crude APIs? How many more applications are there? Most of 50 to 60% of our API are basic crude applications and the application logic in them as in a crude application I'm saying the application logic in them is common like if you delete a track or if you delete a session all the related resource with it will be unlocked in a post-quest database and it will just be deleted. This is called soft-delete which we modified the Flash Regression API we made a fork of it and we modified it to include that So soft-delete just includes deleted at timestamp if the timestamp is there the object has been soft-deleted otherwise it has been not soft-deleted. You can mention it via a query param if soft-delete is no then the recording will be permanently deleted. Any other questions? Sorry, I don't have any idea about it. The main thing in the decision making for the JSON API process that we decided to actually use Ember for the function and Ember has a great support for Ember data Ember data is a JSON API adapter So the real reason for initial reason for using the JSON API specification was that we are going to use Ember on the function and we need it Thank you very much