Swedish web site
TDP013 Web Programming and Interactivity
NodeJS, Express, Mocha, Istanbul & MongoDB
Learning objectives
From the syllabus: Link to syllabus
- Create rich web pages that include dynamic information, interactivity and database connectivity;
- Using programming languages such as JavaScript and NodeJS to create interactive Web content.
Aims
This lab aims to provide a basic understanding of Node.js, MongoDB, testing code using Mocha, and testing code coverage with Istanbul or Istanbul/nyc.
Implementation
The laboratory is carried out in pairs according to webreg (individually or in groups of two). Students are responsible for installing the necessary software to develop with Node.js and MongoDB.
When submitting, a README.md must contain instructions for how to run and test the code. Keep in mind that extra instructions may be needed if, for example, you choose to set up your database on your own server.
Requirements
- It should be possible to save a new message in MongoDB via an HTTP call.
- It should be possible to retrieve a message in MongoDB via an HTTP call.
- It should be possible to mark a message as read/unread in MongoDB via an HTTP call.
- It should be possible to retrieve all messages that have been saved in MongoDB via an HTTP call.
- Calls to pages that do not exist should return HTTP 404.
- Calls to a page with the wrong method should return HTTP 405.
- Calls to a page with incorrect parameters should return HTTP 400.
- All other errors should return HTTP 500.
- Calls to your backend should be made according to one of the specifications below (indicate in your README.md, which specification you have chosen to follow).
Note:It is okay to extend the specification with additional functions as needed. - All messages should be validated in the backend and it should not be possible to add unauthorized messages to the database.
- All calls and all types of incorrect calls should be tested with Mocha.
- Istanbul should be used to generate code coverage reports. You should be able to justify why parts of your code are not included in the report.
- Protection against (common) injections in HTML and MongoDB should be available.
- The information in the database should be retained if the server is restarted.
Tips: You cannot usually rely on the client to send the correct timestamp or ID when adding messages. It might be wise to handle this in the backend instead. Also keep in mind that unique IDs must be unique in the database even if the server is restarted.
Demonstration
Before submitting a lab, you need to present your solution to an assistant. During the presentation, discuss the following reflection questions:
- Describe the structure and flow of your code and demonstrate that it works.
- Describe how your tests work. Go through one of the more complicated tests in detail.
- Describe what a callback function is and how you use it in your code?
- Describe how you use asynchronous calls in your code.
- What parts of your code are not included in the code coverage report and why?
Specification 1
| Function | Call | Method | Parameter type | Example | Return Value |
|---|---|---|---|---|---|
| Save messages | /messages | POST | application/json | { message: "My tweet" } | HTTP 200 |
| Mark as read/unread | /messages/{id} | PATCH | application/json | { read: false } | HTTP 200 |
| Get messages | /messages/{id} | GET | application/json | ||
| Download all messages | /messages | GET | application/json |
Specification 2
| Function | Call | Method | Parameter type | Example | Return Value |
|---|---|---|---|---|---|
| Save messages | /save | POST | application/json | { message: "My tweet" } | HTTP 200 |
| Mark as read/unread | /flag | POST | application/json | { id: 1234, read: false } | HTTP 200 |
| Get message | /get | GET | URL-parameter | ?id=1234 | application/json |
| Download all messages | /getall | GET | application/json |
Page responsible: Huanyu Li
Last updated: 2026-08-24
