Closed tanhengyeow closed 7 years ago
Are you doing server-side rendering or an SPA/API approach? I see that your package.json
has mixed server side packages and client side packages together. Not sure if it's by intention or by accident.
Revision History (could explore using this https://github.com/reactjs/react-router-redux)
How will react-router-redux
be used to implement revision history? Revision history is not a trivial thing to implement. You'll need some diff-ing tool (something like Git). Would recommend that you leave this out of your project at the moment.
The architecture of your application is not clear. What is the role of express in your application?
Is there user authentication required for this? I see that you mentioned that students can update it anonymously. If there is no user login required, you might not even need a server; the front end can interact with Firebase directly.
However, I do think there's a need for user authentication. If not anyone can just deface the content and there's no way of tracing who did that. When dealing with Firebase, beware of authentication issues also. If the Firebase policies are not properly set, anyone can just wipe out your whole database 💥
Module reviews can be done directly on your site. If your wiki goes well, we can shift the NUSMods reviews over to the wiki instead / or integrate the wiki into NUSMods.
Nice mockups btw! Tip: Use text placeholders to show more details in the mockups.
Hey @yangshun! Thanks for the feedback!
How will react-router-redux be used to implement revision history? Revision history is not a trivial thing to implement. You'll need some diff-ing tool (something like Git). Would recommend that you leave this out of your project at the moment.
We thought of implementing revision history but wasn't sure how we are exactly going to do about it. Chancing upon the mentioned resource, we thought we could explore and work with the history instance. However, this can be marked under potential enhancements at the later stage of the project phase once we got the basic building blocks of the project up first. Our primary concern is that users may overwrite useful content with content that is not constructive. We would like to seek some advice on some things we could do to control such behavior.
Are you doing server-side rendering or an SPA/API approach?
However, I do think there's a need for user authentication. If not anyone can just deface the content and there's no way of tracing who did that. When dealing with Firebase, beware of authentication issues also. If the Firebase policies are not properly set, anyone can just wipe out your whole database 💥
We plan to do server-side rendering with express. We are slightly concerned on the issue of logging in to post resources since students might be not in favor of the idea of logging in. However, we agree that security should be of utmost priority and authentication is needed. In this case, we can also use the server to handle different user sessions and interact with firebase.
I don't think most people will prank the system by overwriting useful content. A more realistic concern is a race condition in the editing of the content, where User A and User B are editing the same content at the same time and the later person that hit saves will overwrite the previous guy's changes. Few ways around this:
Store every revision in the database and make sure the user is always editing the latest version of the content. If the content has been changed while the user is editing it, prompt him to refresh because there's a new version. Downside is that you'll have to save each version and it can consume a lot of space. It's also not trivial to publish the update event to currently editing clients. Then again, this will be a rare case. It's probably not worth the effort to implement it.
Do not have shared content that can be modifiable by multiple people. Stuff like past lecturers/useful links/projects can be implemented in a list format, and people either add/remove to that list. There won't be race conditions when there are is no editing involved. You don't have to store the revision history either. This would be much easier to do and I recommend this.
If you're going to do server-side rendering, then I would recommend using next.js. It's not easy to build a server-side rendered React app yourself especially if you are new to React.
Closing this since Orbital has ended. Hope you guys enjoyed your summer 😄
NUSMods Wiki
Scenario
Information about NUS modules can come from official NUS sources or through other platforms like blog posts, youtube etc. Currently, NUSMods has a dedicated module page for each module, showing reviews, module information and timetables. However, users need to search for other resources about modules on their own as these information is scattered over the internet.
As a solution to this problem, we would like to create a wiki platform where students are able to collaborate and share resources on a module anonymously.
This initiative would allow users to quickly obtain information about a respective module. The focus of this platform is to include more user-generated content that is editable by non-technical users. Each module would have a wiki page with some static content obtained from the NUSMods API and the rest of the content would be maintained and updated by students/lecturers.
Implementation Plan
Features
Technology Stack
Front-end development is our focus in creating NUSMods Wiki. It has to be attractive and simple for students to use the platform. We are adopting the following technology stack:
Sample package.json file
Sample server.js file
Sample database.js file
Sample Mockups
NUSMods Wiki Homepage
NUSMods Wiki Module Page
Policy for Quality Control
Timeline