Conference Management System #3

Team 4
April 16, 2024

1 Frontend
1.1 Tech Stack & Architecture
For the frontend development the NextJS framework has been used. It provides useful functions for
routing between pages, fetching data and splitting the components. Also the entire frontend was
written in TypeScript because of its compatibility with types. All components that have been used in
the frontend have been built with TailwindCSS, NextUI and ReactJS. To view a pdf on the site the
ReactPdfViewer component has been used. All icons displayed on the page are either from NextUI or
HeroIcons.
The GitHub repository that was created for the frontend development has been secured by disal-
lowing pushes directly to the main branch, therefore only allowing merges that were previously created
as a Pull Request. Also a pipeline runs on every Pull Request and commit on the main branch, to
ensure that the application can be built and deployed. The main branch always gets automatically
deployed on a Vercel server on every new commit through the pipeline provided by Vercel. Vercel was
the initial choice, because the framework NextJS and the component library NextUI are also developed
by Vercel.

1.2 Authentication
When accessing the site a middleware checks if the user is authenticated. If they aren’t it automatically
redirects to the login page, where the user can then login. After they have authenticated, they can
access all other sites.
One of the example users has the following properties:

• email: [email protected]

• password: password1

1.3 Routes
There are many routes for different purposes in the frontend.

• /: The home page, that only displayes a welcome message to the user. Unfortunately due to
missing interfaces to other projects there is only mock data displayed here.

• /login: The login page. It appears every time the user is not logged in or their session is timing
out (after 10 mins).
• /reviews/list/open: This page displays all reviews that are currently in the ”open” state for
the logged in user.

• /reviews/list/draft: This page displays all reviews that are currently in the ”draft” state for
the logged in user.
• /reviews/list/submitted: This page displays all reviews that are currently in the ”submitted”
state for the logged in user.

1
 • /review/reviewId: This page opens a review, after the user clicked on the button on a ”open”
or ”draft” review object.
• /paper/paperId: This page shows a paper that the user already submitted. It also shows all
reviews that were submitted by other users for the paper. The user can navigate here from every
”submitted” review object.

1.4 Review Site

On the review site a user can enter review details. There are 3 fields that the user can fill before
submitting a review.
On the top, there is a slider, where the user can choose a rating for the paper. When the rating
is below 0, the paper gets rejected and therefore the slider turns red. Over 0 a paper is accepted by
default and therefore the slider turns green. When the rating stays at 0, the reviewer is unsure and
therefore more people have to review a paper before it’s accepted or rejected.
Below the slider there is a textfield, where the reviewer can put in their review details. These
will be displayed on the paper site later. The second textfield is for review comments, which only get
displayed to other reviewers.
The comments of other reviewers can be access through a button press, which opens a dialog where
all the comments from other reviewers get displayed.
At the bottom of the site the reviewer can either submit a draft, which only saves it for himself,
or submit the review finally, which opens it up for everyone who accesses submitted papers.

1.5 Navbar and Footer

The Navbar is located at the top of the page. It shows a custom logo on the left. In the middle there
are options for the Home-Page and for the review pages. On the left there is either a button for Login
or Logout, depending on if the user is currently authenticated and in an active session.
At the bottom there is a Footer, that displays two QR-Codes on the left, which lead to the reposi-
tories for the front- and backend. In the middle there is a little message from our Team. On the right
there would be the possibility for about pages, but as they are not required at the moments the links
are all deactivated.

1.6 Responsiveness
The site will scale depending on the viewport size. For example on the review site, when the viewport
is big enough it will be displayed in 2 columns, but after the viewport shrinks it will change to a single
column. The same happens on all the review list sites and on the paper site.
What still has to be changed is the navbar not scaling properly, as it doesn’t display the options
anymore after shrinking the viewport too much.

2
2 Backend
2.1 Tech Stack & Architecture
The Express Framework is used for the backend development. Also, the backend part of the project
developed with the Monolithic Architecture. The backend project is deployed on Heroku and you can
find the all the endpoints and responses on the Postman Document. In addition, a Heroku pipeline
is generated for the pushes to the ”main” branch. Nobody can push the code directly to the main
branch. Thus, developers have to open ”pull requests” to the main branch and when a development
branch merges to the main the pipeline starts the deployment.

2.2 Models
Models typically contains the data models or schemas that define the structure of the data used in
the application. These models represent the entities in the application and how they relate to each
other. We have three models related with the each other: User, Review, Paper. You can check the
ERD diagram at the Appendix section 1.

2.3 Controllers
The controller is a set of functions that handle the logic for different routes or endpoints defined in your
application. There are three different controllers in the project: papers controller, reviews controller
and users controller. All the CRUD (Create, Read, Update, Delete) operations done by the controller.
You can check the class diagram at the Appendix section 2.

2.4 Middlewares
Middleware functions in Express are functions that have access to the request object (req), the response
object (res), and the next middleware function in the application’s request-response cycle. Middleware
functions can perform tasks like parsing request bodies, logging, authentication, authorization, error
handling, and more. There is a middleware in the project: authMiddleware. It intercepts the all
requests and checks the user token for authentication. You can check the class diagram at the Appendix
section 3.
c o n s t decoded = jwt . v e r i f y ( token , ’ y o u r s e c r e t k e y ’ ) ;
r e q . u s e r = a w a i t User . f i n d B y I d ( decoded . u s e r I d ) ;
next ( ) ;

2.5 Routes
Routing refers to how an application’s endpoints (URIs) respond to client requests. There are different
routes for different domains.
// F i l e : app . j s
app . u s e ( ” / p a p e r s ” , paperRoutes ) ;
app . u s e ( ” / u s e r ” , u s e r R o u t e s ) ;
app . u s e ( ” / r e v i e w s ” , r e v i e w s R o u t e s ) ;
app . u s e ( ” / r e v i e w ” , r e v i e w R o u t e s ) ;

// F i l e : r o u t e s / r e v i e w . j s
// POST / r e v i e w
router . post ( ’/ ’ , reviewController . createReview ) ;
// . . . .

3
3 Database
3.1 Tech Stack & Architecture
The database deployed on the Mongo DB Atlas via Amazon Web Services. We define the relations
showed on the ERD diagram as embedded relations. There is embedded user and paper information
in the Data-Transfer-Object of the review model. C

3.2 Connection
Connection between the database cluster and the project supplied by the connection string. The
backend app connects to the database while it is spinning up.
c o n s t mongoose = r e q u i r e ( ’ mongoose ’ ) ;
c o n s t u r i = ” your c o n n e c t i o n s t r i n g ” ;

c o n s t run = async ( ) => {

a w a i t mongoose . c o n n e c t ( u r i )
. then ( ( ) => {
debug ( ” Connected t o MongoDB ” ) ;
// Now you can p r o c e e d with your a p p l i c a t i o n i n i t i a l i z a t i o n
})
. c a t c h ( ( e r r o r ) => {
debug ( ” E r r o r c o n n e c t i n g t o MongoDB : ” , e r r o r ) ;
});
}

3.3 Mocking
Mock data refers to simulated or artificial data used for testing, development, or demonstration pur-
poses. It’s designed to resemble real data in terms of structure and format but doesn’t contain actual,
sensitive, or confidential information. There is a script for inserting some dummy users into the
database. See the script result at the appendix section 4.
// Connect t h e db
// . . .

// U s e r s a r r a y
const users = [
{
e m a i l : ’ user1@example . com ’ ,
password : a w a i t b c r y p t . hash ( ’ password1 ’ , 1 0 ) ,
}
// . . . . .
];

// I n s e r t a l l t h e data
a w a i t User . insertMany ( u s e r s ) ;

4
A Appendix A: Entity Relation Diagram

Figure 1: Entity Relation Diagram

B Appendix B: Controller Class Diagram

Figure 2: Controller Class Diagram

5
C Appendix C: Routes Class Diagram

Figure 3: Routes Class Diagram

D Appendix D: Mock Script Result

Figure 4: Mock Script Result