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

• react-scripts are used for something
• redux-thunk?
• tests

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.