Refactoring Suggestions

[pengyin-shan]

I list all possible front-end code refactoring steps here. I'll continue to add/update tasks, based on our development timeline. If we get a tight timeline ahead of us, I'll focus more on finishing the development of the work. Otherwise, I can work on the refactoring tasks:

• [ ] Take in-line styles out and use SASS to manage the style platter, so that the theme could potentially be used somewhere else. Webpack setting will also be updated.

• [ ] Take some common building blocks in both the home page and EQIP page, then create components for them.

• [ ] If we going to continue to use the MUI library, it might be possible to create our own MUI component library. Not sure if it is possible, so I'll talk to Leigh and navigate the solution

• [ ] If we decide to add mobile support later (for now, our site is not working on both phones and tablets), we need to start now before more code is added. I personally suggest adding support for mobile devices considering their popularity, but it depends on the team's decision.

• [ ] We don't have any unit tests for now. I removed unused tests from the original template in #71 . After we get API work, we can begin to 1) add tests in the front end to validate JSON data 2)Add extra design to prevent cases that API doesn't work (a contact box or a user-friendly error message)

• [ ] Accessibility check reflected that we have 14 critical issues to fix before we can reach the WCAG 2.1 AA standard standard. Most of them are missing labels, which should be easy to fix.

---

@navarroc what's your option about this? So far I plan to push forward with CSP and SNAP page first (if we need them very soon), then I'll gradually work on refactoring work.

[pengyin-shan]

After having a one-on-one with Yoo Wook (and confirming we will only allow GET requests), I'm adding new consideration for data validation and securities after connecting to API:

• [ ] For the front end, we need to add a vulnerability check library to prevent possible security threats, such as DDOS attacks. Synk (https://github.com/testing-library/react-testing-library) looks like a reliable library with lots of forks and stars. I'll navigate it and see if it can help us

• [ ] whitelist/blacklist of IPs for API portal?

• [ ] Based on the design of the database, the front end will set up a reasonable request frequency (10mins, 1 hour, overnight?). The backend should be block suspicious requests if not following this frequency

[ywkim312]

After having a one-on-one with Yoo Wook (and confirming we will only allow GET requests), I'm adding new consideration for data validation and securities after connecting to API:

• [ ] For the front end, we need to add a vulnerability check library to prevent possible security threats, such as DDOS attacks. Synk (https://github.com/testing-library/react-testing-library) looks like a reliable library with lots of forks and stars. I'll navigate it and see if it can help us
• [ ] whitelist/blacklist of IPs for API portal?
• [ ] Based on the design of the database, the front end will set up a reasonable request frequency (10mins, 1 hour, overnight?). The backend should be block suspicious requests if not following this frequency

@pengyin-shan There is some misunderstanding in here. We will not only allow GET requests. We only have GET endpoint at this moment. We will allow or have POST, PATCH, or DELETE if needed.

[ywkim312]

@pengyin-shan I also have questions about your check points As for the DDOS, the API only will only accept the connections inside the NCSA and reject all the outside ones as we had conversation. Is there a possibility that the DDOS comes inside NCSA?

As for the whitelist/blacklist, we already have it that we are only allowing the ips inside the NCSA as we had a conversation about it. Is there any other list be needed to protect the incoming from NCSA?

I still don't understand about the third one like I was not very sure during our conversation. Do you mean that the same ip's request call using the frontend should be delayed like 10 min? For example, you browse the all program map from the frontend, that needs api call for the attributes, then you need to wait 10 min to see other maps that also needs api call for the attribute from the frontend? Sorry, I still don't understand this part very clearly.

[pengyin-shan]

After having a one-on-one with Yoo Wook (and confirming we will only allow GET requests), I'm adding new consideration for data validation and securities after connecting to API:

• [ ] For the front end, we need to add a vulnerability check library to prevent possible security threats, such as DDOS attacks. Synk (https://github.com/testing-library/react-testing-library) looks like a reliable library with lots of forks and stars. I'll navigate it and see if it can help us
• [ ] whitelist/blacklist of IPs for API portal?
• [ ] Based on the design of the database, the front end will set up a reasonable request frequency (10mins, 1 hour, overnight?). The backend should be block suspicious requests if not following this frequency

There is some misunderstanding in here. We will not only allow GET requests. We only have GET endpoint at this moment. We will allow or have POST, PATCH, or DELETE if needed.

Oh sorry, let me clarify: for all considerations here, I just raise possible plans. None of them have to be implemented. They are just ideas and it depends on our team's decision to process them or not.

2): Since we are certain that NCSA already set up prevention rules to cover all its apps, we can skip DDOS prevention and whitelist/blacklist setup.

3): The last thing is about refreshing data from the front end. For example, if our database is refreshed every 10 mins, then I want to set up the front-end to fetch data every 10 mins also, so that the user can always see updated data. Or if we gonna do an overnight rebuild and we are ok with keeping a static page in day hours, then I don't need to set up intervals, instead the rebuild will fetch the newest data every night.

What I'm considering here is the case that we notice abnormal fetching frequency (for example, the backend noticed that our API is called once every 1 second instead of 10 min). Then there's something wrong and we should be notified. NCSA probably also already took care of this. Anyway, again this is a team decision. We can choose to skip this.

[ywkim312]

After having a one-on-one with Yoo Wook (and confirming we will only allow GET requests), I'm adding new consideration for data validation and securities after connecting to API:

• [ ] For the front end, we need to add a vulnerability check library to prevent possible security threats, such as DDOS attacks. Synk (https://github.com/testing-library/react-testing-library) looks like a reliable library with lots of forks and stars. I'll navigate it and see if it can help us
• [ ] whitelist/blacklist of IPs for API portal?
• [ ] Based on the design of the database, the front end will set up a reasonable request frequency (10mins, 1 hour, overnight?). The backend should be block suspicious requests if not following this frequency

There is some misunderstanding in here. We will not only allow GET requests. We only have GET endpoint at this moment. We will allow or have POST, PATCH, or DELETE if needed.

Oh sorry, let me clarify: for all considerations here, I just raise possible plans. None of them have to be implemented. They are just ideas and it depends on our team's decision to process them or not.

2): Since we are certain that NCSA already set up prevention rules to cover all its apps, we can skip DDOS prevention and whitelist/blacklist setup.

3): The last thing is about refreshing data from the front end. For example, if our database is refreshed every 10 mins, then I want to set up the front-end to fetch data every 10 mins also, so that the user can always see updated data. Or if we gonna do an overnight rebuild and we are ok with keeping a static page in day hours, then I don't need to set up intervals, instead the rebuild will fetch the newest data every night.

What I'm considering here is the case that we notice abnormal fetching frequency (for example, the backend noticed that our API is called once every 1 second instead of 10 min). Then there's something wrong and we should be notified. NCSA probably also already took care of this. Anyway, again this is a team decision. We can choose to skip this.

@pengyin-shan Thank you for the answer 👍 As for the third one, does front end need to patch or update the data into the front end? As far as I know, it is real time requesting instead of the patch if it uses the api end point, but I am not 100 percent sure.

[pengyin-shan]

After having a one-on-one with Yoo Wook (and confirming we will only allow GET requests), I'm adding new consideration for data validation and securities after connecting to API:

• [ ] For the front end, we need to add a vulnerability check library to prevent possible security threats, such as DDOS attacks. Synk (https://github.com/testing-library/react-testing-library) looks like a reliable library with lots of forks and stars. I'll navigate it and see if it can help us
• [ ] whitelist/blacklist of IPs for API portal?
• [ ] Based on the design of the database, the front end will set up a reasonable request frequency (10mins, 1 hour, overnight?). The backend should be block suspicious requests if not following this frequency

There is some misunderstanding in here. We will not only allow GET requests. We only have GET endpoint at this moment. We will allow or have POST, PATCH, or DELETE if needed.

Oh sorry, let me clarify: for all considerations here, I just raise possible plans. None of them have to be implemented. They are just ideas and it depends on our team's decision to process them or not. 2): Since we are certain that NCSA already set up prevention rules to cover all its apps, we can skip DDOS prevention and whitelist/blacklist setup. 3): The last thing is about refreshing data from the front end. For example, if our database is refreshed every 10 mins, then I want to set up the front-end to fetch data every 10 mins also, so that the user can always see updated data. Or if we gonna do an overnight rebuild and we are ok with keeping a static page in day hours, then I don't need to set up intervals, instead the rebuild will fetch the newest data every night. What I'm considering here is the case that we notice abnormal fetching frequency (for example, the backend noticed that our API is called once every 1 second instead of 10 min). Then there's something wrong and we should be notified. NCSA probably also already took care of this. Anyway, again this is a team decision. We can choose to skip this.

@pengyin-shan Thank you for the answer 👍 As for the third one, does front end need to patch or update the data into the front end? As far as I know, it is real time requesting instead of the patch if it uses the api end point, but I am not 100 percent sure.

Well probably I misunderstand... I was thinking about the situation in that a user is looking at the page...meanwhile our database gets updated when this user is still having the page open. Then am I supposed to reflect the newest data to the user, immediately? If not we are all good to go. If yes, then I'll adjust the front end a little bit so that the loading period is minimal. And React might also have a good solution for this already that I can refer to.

[navarroc]

DB updates would probably happen annually. Maybe twice a year if we get partial year data so pretty infrequently.

[pengyin-shan]

DB updates would probably happen annually. Maybe twice a year if we get partial year data so pretty infrequently.

Ah nice, then we don't need to worry about the real-time update. The frequency is less than I expected.