This post focuses on the project of developing a 'Conference Management Tool' under Application Frameworks module. The review of the first phase of this module can be found here . This is the second part of the review.
Once the basic upload and download functionalities are developed, the upload component was needed to be associated with the registration of the research paper presenter. Since the registration form was necessary to be developed for that to be done, the integration part will be done in a future point. This might be a place where the methods of a nested component will have to be called from a parent component.
Apart from just uploading and downloading research papers there were other functionalities that needed to be addressed. The reviewers must be able to approve or reject the research papers after reviewing them. There might be situations that research papers get rejected and researchers need to re-upload the modified file under the same id. There might also be the need to delete an research paper upload entry entirely. Even though completely dropping a research paper entry might seem unnecessary it might be needed in some rare circumstances such as security concerns.
In implementing reviewers' functionality, reviewer should be able to see every research paper upload entry and details regarding the upload entries. For that a separate component was implemented where all the entries were drawn into a table structure and shown. In the table, the reviewers can mark the entry as approved, or rejected. If they make a mistake, they can revoke the entry status back to pending. After changing the status the changed status should be shown in the table. For updating the status, the componentDidMount method was called if the change of status at the back end was successful. Then the updated component would get rendered if the update was successful.
Here, I noticed a lag when loading the data and updating the status. It would take some time to load the data to the table once the component was rendered. I brought up this issue in a discussion with our team members and apparently the issue was in loading the data from the database. The reason we suspect is the MongoDB cluster we use. We are using a free online MongoDB cluster, and the member who created the MongoDB cluster stated that this cluster may not be located closer to us. So, it is important to keep in mind that if a service we are using is not located closer to us may cause in lags. It will be important to pay attention to where you will create your services when creating an application.
The same issue was present in loading data in the delete component as well. The only apparent solution to this issue will be to recreate the cluster in a location that is closer to us. This will be a more complex issue to solve in an application that will be deployed and consumed globally since users around the world will try to access the resources from the database. Some users who are distant from the location of the database will experience will performance issues. More research must be done on how address those type of issues in large scale application. The apparent solution will be to host the same resources redundantly in several location of cloud service providers.
From this experience we can conclude that we should pay attention to the following points when creating a database cluster.
- Who are the target audience (users) of the system? are they concentrated in a single geographical location or are they widespread around the globe?
- What is the budget allocation?
- Where are the majority of the developers located?
- What will be the plans to improve the performance and speed of the system?
From analyzing the above situation it can be stated that if we pay attention to the above points, formulate a proper strategy implementation as well as deployment of the created system will be more successful.
Comments
Post a Comment