The assignment for the module aims to assess your understanding and knowledge in the design and implementation of a dynamic web app for a given specification.

Individual-based assessment due on the 21 July 2025 on/before 11:59am (submission via Canvas). This is an individual assignment that contributes 100% of the overall assessment for the module. Resit submissions will be capped at 50% whereas deferral submissions (on approval from the exam board) will be uncapped.

The assignment for the module aims to assess your understanding and knowledge in the design and implementation of a dynamic web app for a given specification. The web app must be implemented utilising the core client-side and server-side technologies covered in the module:

  • HTML (The Living Standard)
  • CSS (CSS Snapshot 2024)
  • JavaScript (client & server)
  • Node JS (Node.js 20.x)
  • Express JS
  • Embedded JavaScript templates (EJS)
  • MySQL (8.0 or below)

Please double-check your MySQL server is the correct version of 8.0. XAMPP uses

MariaDB and is generally considered equivalent to MySQL 8.0 in terms of features and functionality. However, because MariaDB is a fork of MySQL, there may be differences in some features and optimisations.

Make sure to test your web app on a modern browser (e.g., Google Chrome, Firefox, Safari). The assessment process may use a mixture of modern browsers.

Use of popular frontend JavaScript frameworks like React, Vue.js, Angular, Svelte, Ember.js, Backbone.js, Preact, Next.js, Nuxt.js etc is not permited . There is enough scope within the above stack to allow your web development skills to be assessed 

Journal iSOxx web app overview

A web app designed for secure, organised, and intelligent personal journaling. Journal iSOxx is a web application aimed at users who want a secure, structured, and smart journaling experience. The app allows users to create journal entries, tag them, search intelligently, and back them up securely, with optional mood tracking and external smart data addition.

Note: `Optional` features are intended for those aiming to develop a more advanced system and potentially achieve higher marks.

Requirements core features

1.1  User Accounts 

  • Sign up / Log in via email
  • Password reset & account deletion
  •  

1.2  Journal Entry

  • Create, edit, and delete journal entries.
  • Add metadata: date, time, tag(s), location, friends and/or family.
  • Optional: Auto-save while writing.
  • Optional: Rich text formatting (bold, italics, bullet points). 

1.3  Mood Tracking

  • Arbitrarily add a mood(s) (selectable) to a Journal entry.

1.4  Media Attachments 

  • Add photo/image to journal entries (single asset).
  • Optional: Add many photos /images to journal entries and limit number of attachments per entry (configurable).

1.5  Tagging and Organisation 

  •  View entries by tag cloud, calendar, or list.
  •  Pin/star important/favourite entries.

1.6  Nested Sub-Entries/Subsections in Journal Entries (Optional)

  • A main entry may contain zero or more sub-entries.
  • Sub-entry shall have: A title (optional), Body text (required), Timestamp (automatically captured or user-defined), Tags (optional, inherited or custom), Mood (optional, can differ from main entry), images (none to many).

1.7  External Data Integration for Journal Entry Context (Optional)

  • Upon journal entry creation, the app shall retrieve external data automatically
  • External sources should be used e.g. weather API, map (location) API etc, to enhance the user experience.

1.8  Search & Filters 

  • Full-text search across entries.
  • Filter, for example, by date, tag, mood, keyword, friends, family.
  • Saved searches.

1.9  Insights (Optional)

  • Word frequency analysis.
  • Mood trend over time.
  • Writing streaks and activity visualisation.

Non-Functional Requirements

2.1  UI & UX

  • Modern.
  • Responsive.

2.2  Data Storage

The Journal ISO application shall use MySQL as the primary relational database management system (RDBMS) to persist and manage structured data, including user accounts, journal entries, metadata, and system settings.

2.3  Security

The Journal ISO web application shall implement robust security practices to protect user data, prevent unauthorised access, and ensure integrity and confidentiality of user content. Validation on both client-side e.g. input forms. Server-side security for both the application tier and the data tier should be considered.

2.4  GitLab Repository Usage for Version Control 

All source code, configuration files, and relevant documentation for the Journal ISO application must be version-controlled using a GitLab repository.

Technical Architecture Requirement

3.1  The Journal ISO system must expose and consume data through a well-structured RESTful API architecture, enabling modular, scalable, and maintainable communication between the frontend, backend, and external services. 

System Architecture 

Code Approaches 

RESTul Application Programmable Interface. The system should incorporate and utilise a standalone REST API that provides an abstraction of the back-end MySQL database which allows the interaction with the back-end MySQL database using an appropriate set of REST API verbs. Responses from the API should be provided correctly in JSON format.

Implementation of architectural patterns is allowed but not core requirement. Responsibility delegation is important in modern development. As it often delegates to underlying logic, like a Controller or ViewModel, rather than making decisions in the

view itself. 

Concentrate on achieving a KISS (Keep It Simple, Stupid) approach. Focus on simplicity. Simplicity is Key, write code that is straightforward and easy to understand. Avoid over-engineering or implementing overly complex solutions. Your code should be understandable not just by you but also by others. The more dependencies a system has, the more likely it is to break. Avoid writing "future-proof" solutions that address

problems you don`t currently have. KISS doesn`t mean oversimplifying or avoiding complexity where necessary. Instead, it’s about balancing simplicity with functionality. By focusing on clarity and purpose, you can write code that’s easier to understand, maintain, and extend.

Implement a DRY principle (Don’t Repeat Yourself). This a fundamental concept in software development aimed at reducing redundancy by ensuring that every piece of knowledge or logic in a system is represented in a single, unambiguous way. The DRY principle emphasises maintainability and efficiency by avoiding duplication in code, logic, or processes. If the same piece of functionality or data exists in multiple places, changes or updates can lead to inconsistencies and increased maintenance effort.

Use GIT and your Gitlab.eeecs.qub.ac.uk platform/service for commits. You want frequent commits: Commit often to save your work and create a detailed history. This makes it easier to revert changes if needed. Atomic commits: Each commit represents a single, logical change. This ensures that your commit history is easy to follow and understand. Clear and concise commit messages, using the imperative mood (avoid describing events passively).

Assignment Tasks & Deliverables

To fulfil this assignment specification, you are required to complete the following tasks: 

  • Design, develop and test an interactive Node-based web app to achieve the stated requirements using relevant client-side (e.g., HTML, CSS, JavaScript) and server-side (e.g., JavaScript, Node JS, Express JS, EJS templates, MySQL) web development technologies covered in the module. You are permitted to utilize client-side CSS libraries and frameworks, e.g., Bootstrap, Bulma, Tailwind, etc., client-side JavaScript libraries, e.g., jQuery, Chart JS, etc., or other external JavaScript Node modules installed using NPM. However, you are not permitted to use JavaScript front-end frameworks, e.g. React JS, Vue, Angular. NoSQL database implementation is also not permitted.

Deliverable 1: Project Files. A compressed (zip) file containing the project folder(s) with all source code files and resource files used for the implementation of the web app, including a folder containing the exported database tables, and a brief readme file detailing any build instructions and instructions for running the web app, should be uploaded via the Source Submissionlink on Canvas. The zip file should be named yourstudentnumber.zip (i.e., 12345678.zip). Please note the node_modules folder should not be included within the project folder.

Deliverable 2: Technical Report. Include your report in PDF format within the Project Files folder. The report should be named yourstudentnumber.pdf (i.e., 12345678.pdf). It is your responsibility to ensure the PDF can be opened and viewed. Reports submitted in formats other than PDF won’t be accepted by the submission link. Contents of reports beyond the maximum page limit will not be used during marking. The Technical Report, which briefly details the design decisions and technical artefacts of the web app’s implementation. Guidelines outlining the content required in the report can be found in the Report Guidelines section later in this assignment specification. 5 page maximum.

Deliverable 3: Exported gitlog.txt Open a terminal window in the local GitHub repo copy of your source code and run the following command: 

git log --numstat --date=iso-strict > gitlog.txt 

Failure to submit a deliverable will result in a mark of 0%. Students must ensure submitted materials can be successfully opened, decompressed and viewed. Corrupt files will be treated as a non-submission. Make sure to test your uploaded submission, for example, download your submission from Canvas and run your app.

Deliverables must be submitted by the following deadline: Monday 21 July 2025

11:59am. Except for students that have been granted an extension by the Exceptional Circumstances Panel, either due to circumstances or under an Individual Student Support Agreement (ISSA), a penalty for late submissions will be applied as follows:

“Coursework submitted after the deadline will be penalised at the rate of 5% of the total marks available for each calendar day late up to a maximum of five calendar days, after

which a mark of zero shall be awarded, i.e., up to one calendar day is 100% - 5%; up to two calendar days is 100% -10%; up to three calendar days is 100% - 15%, etc.”

Report Guidelines

The following guidelines outline the expected content of the technical report and provides details of the design decisions made and technical artefacts created during the implementation of the web app:

  • Name, Student Number and QUB email. URL of the accessible project’s gitlab.eeecs.qub.ac.uk repo (make sure to add module tutor as a Developer).
  • Outline the development design decisions made regarding the set of implemented functional requirements. The contents of this section should identify the software design patterns choices made, along with a short rationale where appropriate. (2 page maximum).
  • Provide an ER diagram of the final MySQL database used. (1 page maximum)
    • List any API endpoints implemented along with their corresponding REST API verbs. The contents of this section should be a list of all REST API endpoints that have been implemented within the web app. For each endpoint the corresponding REST API verb should also be given. (1 page maximum)
    • Provide references for any supporting sources of information or external code snippets used during the development of the web app. The contents of this section should be a list of references to all sources used during the development of the web app. Please note you do not need to include references to the content from the CSC7062 module.

The report should use a 11pt font size, single line spacing and be saved as PDF format. A cover page is not required, and the reference list is not included in the total page count. Report content given beyond the 5-page maximum limit will not be used in the marking of the assignment. 

Marking Criteria & Rubric

An indicative marking rubric based on the University’s Postgraduate Taught Conceptual Equivalents Scale is provided at the end of this assignment specification, with the following component weightings: 

Assignment Component

Weighting

 

Presentation Tier

 

15%

 

Application/logic Tier

 

35%

 

Data Tier

 

35%

 

Code Quality & Approach

 

15%

Presentation Tier [15%] 

Consideration of the demonstrated knowledge, understanding and application of client-side technologies. This assignment component focuses on aspects of the navigation, usability and design of web app, which takes into consideration HTML structure and semantics, CSS styling and responsiveness, client-side JavaScript interactivity and related logic.

Application/logic Tier [35%]

Consideration of the demonstrated knowledge, understanding and application of server-side technologies. This assignment component focuses on aspects of the CRUD operations and backend logic underpinning the functionality of the web app, which takes into consideration the corresponding business logic for user and system requirements. 

Data Tier [35%]

Data management using MySQL, handling of security concerns, REST API implementation, and overarching data structure and handling.

Code Quality & Approach [15%]

Consideration of the degree of quality of the project source code. This assignment component focuses on the extent of folder/file structure, modularity, architectural patterns and readability of the source code used for the implementation of the web app.

Consideration of the degree to which the submitted Technical Report adhere to the specified guidelines.

Consideration of git and gitlab.eeecs.qub.ac.uk repo practice and approach. Please note: make sure to add the tutor 2080079. (j.a.busch@qub.ac.uk) as a Developer

  • eeecs.qub.ac.uk Repo > Manage > Members > press the Invite members button
  • Use the UI to add the following details...
100% Plagiarism Free & Custom Written, Tailored to your instructions