Architectural Guide

Reference: https://github.com/csesoc/csesoc.unsw.edu.au

Frontend

“Front end development manages everything that users visually see first in their browser or application”

The frontend is arguably the most important component of the CSESoc website, as it might be the first point of contact for many people. The frontend will statically serve data gathered from REST API calls. The frontend uses the progressive framework developed around vanilla JavaScript: Vue.js

Currently, the frontend communicates with the backend through various asynchronous calls to a REST API server which returns data to build the various components that make up the website. The frontend code resides in a parent directory called src/. The frontend is divided into mainly three directories plugins, components, and views; where main.js is the central point of where the frontend initiates.

The views folder will deal with all website pages that would be directly visible online.
The components folder will allow small completed pieces of frontend parts to be re-used by the website pages.
The plugins folder deals with all the brains behind frontend development.

Current Architecture

The frontend is largely uncompleted at this stage. Ideally, all view Vue files would be responsible of making the appropriate REST API calls and styling their corresponding pages.

TBD Architecture

TBD…

Backend

“Backend development languages handle the ‘behind-the-scenes’ functionality of web applications”

Inside the CSESoc website, the backend’s main purpose is to become the central part of all pieces of information. This means that all communications to retrive specific data will be eventually processed through the backend server. Luckily Go is a simple, yet, powerful language to achieve this using echo, a minimalist web framework.

Additionally, the backend server will serve as a mediator between the frontend and the database. For the database we are using MongoDB.

The backend code resides inside the server/ folder, where server.go contains the main() function to start-up the server.

Current Architecture

In the current architecture server.go maintains all aspects of the API Interface, and holds all struct types that would exist inside the backend. Regarding the currently completed functionalities refer to https://gawdn.com/api-docs/

TBD Architecture

The architecture that is planned over the course of 2020, is to decouple server.go from handling all of the API endpoints and knowing all struct types. Instead, we will have various .go files to handle specific aspects of the website and keeping their structs 'private'.

This will also allow server.go to extend the capabilities of echo by utilising middlewares to deal with security authentications.

Deployment

“Deployment development deals with the design and architecture of the platform on which the files will be served.

In CSESOC’s website, both local and web deployment are critical parts of the DevOps lifecycle, allowing for continuous integration and deployment. With the use of Github Actions for continuous integration and the combination of Docker Hub and Wheatley to continuously deploy ensures that we fulfil the principles laid out in CALMS framework.

Current Architecture

In the current architecture, Dockerfiles are coded to locally deploy with base images of mongo and our own server side image. The file is then used by Github Actions to run the server and automate testing against the deployed server. Dockerhub builds an image from our master branch to serve a container to Wheatley that then deploys it to our hosting server.

TBD Architecture

TBD