Outline for the project

Project outline

Our course project work consists of separate frontend and backend NodeJS applications.

Files associated with the frontend are found in the path /labtool2.0 and the Dockerfile from the repository root. All files associated with the backend are found under /backend path.

Frontend

The frontend of the project (labtool2.0) is structured in a following way:

Index.js and App.js

Index.js is the file that is started when you run the project. It contains some imports for the whole application such as redux provider and redux store, and react-router.

app.js main purpose is to provide the routes for the paths of the application. It also has the navigation bar and is the component that checks that a) user is logged in b) user has set an e-mail. After these two conditions have been met, the routes actually start to function.

Reducer folder and Store.js (Redux)

Reducers are all located src/reducers folder. They make use of Redux to create stores for the application, that it uses to provide the information to be displayed on different pages.

store.js is located on the root on the folder, and imports all reducers created to reducers folder. store.js also imports the middlewares that redux uses, which in this case are thunk, that makes async actions in redux possible, and apiConnection, that is explained below.

Util folder (apiConnection)

apiConnection.js is a middleware that fusions axios, the module that communicates with the api, and redux. You use it with the function "callController" that is inside the file. callController is given the following things:

• route, which is the last part of the api's address that is called (www.api.com/{thisIsRoute})
• prefix, which is the redux dispatch messages identifier
• method, ex post get put
• payload, which is the data that is posted in case of post or put etc.

After this, apiConnections function handleRequest, which is a redux listener, hears the request and puts it on callApi which then calls axios. Then if, the request didnt result in error a prefix_SUCCESS message is dispatched, which other reducers can use to do stuff. If the axios request results in an error, a prefix_FAILURE message is dispatched, which again, other reducers can listen and react accordingly.

Services folder

Services is located in src/services. It contains all the requests that the application uses to make apiConnection calls. It has the paths and prefixes and routes hardcoded which apiconnection uses.

Components

src/components/pages contains all the pages the application uses. They use semantic-ui (https://react.semantic-ui.com/introduction) library and make heavy use of the the redux stores (app.js also uses these!). They also import the api communication methods from services folder.

Backend

1. Is a plain NodeJS implementation

   • less facepalming than with react-scripts

2. Uses Express for application routing into Ruby on Rails alike controllers

   • asd

3. Sequelize ORM is being used as the database backend with its models.

   • PostgreSQL 10.1 version is being used in this project for local development and in the intended deployment environment
   • No model methods have been used since those seemed too complicated to use.

4. Somewhat Ruby on Rails alike application helpers implemented but differentiating

   • /backend/server/helpers/application_helper.js intended to store application wide commonly used functions
   • each controller has its own helper which imports functions from application_helpers and exports them along with the functions associated only to the controller.
   • perhaps not the best way

5. Middlewares located in /backend/app.js and are run before any request is processed

   • extractToken: reads the header Authorization and extracts the token and saves it in the request.token variable
     • perhaps unnecessary completely since the next function may be the sole consumer of the variable
   • authenticate: uses request.token and decodes it with jwt and sets request.authenticated as a json which indicates if the request was "authenticated" or not.
     • application_helpers.js has controller_before_auth_check_action() method which checks request.authenticated and and ends request processing with 401 Unauthorized unless authenticated. This method is seen first at any controller action where the user needs to be authenticated.
     • better way certainly possible to do e.g. having the whole check and discontinuation of request processing in a middleware.

6. Admin page /admin path not in interaction with the frontend.

   • implemented using PUG layout which is again Ruby on Rails alike having its view template in the path /backend/views/index.pug

7. Tests "implemented" with mocha and supertest. Http requests mocked with nock.

Travis & Dockerhub

1. Split into stages, tests and integration tests, where the almost nonexistent tests for backend and frontend are run in separate build jobs and the latter integration test stage with no actual tests run only if the backend and frontend tests both pass.
   • The good thing about not having too many tests at this point is that the project is highly modifiable. Nothing has been carved into stone that something has to be implemented some way.
2. Dockerhub has two main tags which are set to watch changes on the github master and dev branches.
   • It automatically builds a container for each based on the dockerfiles:
     • frontend: /Dockerfile
     • backend: /backend/Dockerfile
   • The containers are not production ready and cannot be as such truely used in production. Instead Dockerfiles should make the containers at runtime build the application using environment variables supplied from the docker-compose.yml
   • more info about the deployment and configuration in the deployment wiki page.