Göm menyn

TDP013 Webbprogrammering och interaktivitet

NodeJS, Express, Mocha, Istanbul & MongoDB

Lärandemål

Från kursplanen: Länk till kursplan

  • Skapa avancerade webbsidor som inkluderar dynamiska information, interaktivitet och databasanslutning.
  • Använda programmeringsspråk som JavaScript för att skapa interaktivt webbinnehåll.

Programmål - Innovativ Programmering

Från programplanen: Länk till programplanen

  • 1. hantverk: den (ofta tysta) kunskap och individuell förmåga som studenten bygger upp genom att arbeta praktiskt med programmering, själv, i projekt och i community. Här betonas både att arbeta innovativt och mot beställare.
  • 3. teknik: kunnande om den teknik som finns för programmering och datorer, med fokus på programmeringsspråk och plattformar.

Examensmål - Kandidatexamen

Från Högskoleförordningen (1993:100): Länk till förordningen

  • visa kunskap och förståelse inom huvudområdet för utbildningen, inbegripet kunskap om områdets vetenskapliga grund, kunskap om tillämpliga metoder inom området, fördjupning inom någon del av området samt orientering om aktuella forskningsfrågor.
  • visa förmåga att söka, samla, värdera och kritiskt tolka relevant information i en problemställning samt att kritiskt diskutera företeelser, frågeställningar och situationer
  • visa förmåga att självständigt identifiera, formulera och lösa problem samt att genomföra uppgifter inom givna tidsramar

Syfte

Den andra laborationen avser att ge grundläggande förståelse för Node.js, MongoDB, testning av kod med hjälp av Mocha och testning av kodtäckning med Istanbul. I labben skapas backend-delen för den Twitter-liknande klienten i laboration 1 men de kopplas samman först i laboration 3.

Genomförande

Laborationen genomförs i par enligt webreg (enskilt eller i grupper om två). Studenterna ansvarar själva för att installera nödvändig programvara för att utveckla med Node.js och MongoDB.
Vid inlämning ska en README.md innehålla instruktioner för hur man kör och testar koden. Tänk på att extra instruktioner kan behövas om ni exempelvis väljer att lägga upp er databas på en egen server.

Krav

  • Det ska via ett HTTP-anrop gå att spara ett nytt meddelande i MongoDB.
  • Det ska via ett HTTP-anrop gå att hämta ett meddelande i MongoDB.
  • Det ska via ett HTTP-anrop gå att markera ett meddelande som läst/oläst i MongoDB.
  • Det ska via ett HTTP-anrop gå att hämta alla meddelanden som har sparats i MongoDB.
  • Anrop till sidor som inte finns ska returnera HTTP 404.
  • Anrop till en sida med fel metod ska returnera HTTP 405.
  • Anrop till en sida med felaktiga parameterar ska returnera HTTP 400.
  • Alla andra fel ska returnera HTTP 500.
  • Anrop till er backend ska ske enligt en av specifikationerna nedan (ange i er README.md vilken specifikation ni valt att följa). OBS:> Det är okej att utöka specifikationen med ytterligare funktioner efter behov.
  • Alla meddelanden ska valideras i backend och det ska inte vara möjligt att lägga till otillåtna meddelanden i databasen.
  • Alla anrop och alla typer av felaktiga anrop ska testas med Mocha.
  • Istanbul ska användas för att generera kodtäckningsrapporter. Ni ska kunna motivera om varför delar av er kod inte finns med i rapporten.
  • Skydd mot (vanligt förekommande) injections i HTML och MongoDB ska finnas.
  • Informationen i databasen ska finnas kvar om servern startas om.

Tips: Man kan i regel inte lita på att klienten kommer att skicka med korrekt tidsstämpel eller ett ID när meddelanden läggs till. Det kan därför vara klokt att hantera det i backend istället. Tänk även på att unika ID:n måste vara unika i databasen även om servern skulle startas om.

Redovisning

Innan en labb rättas behöver ni redovisa er lösning för en assistent. Diskutera under redovisningen nedanstående reflektionsfrågor:

  • Beskriv strukturen och flödet i er kod och demonstrera att det fungerar.
  • Beskriv hur era tester fungerar. Gå igenom ett av de mer komplicerade testerna i detalj.
  • Beskriv vad en callback-funktion är och hur ni använder er av det i koden?
  • Beskriv hur ni använder asynkrona anrop er kod.
  • Vilka delar av er finns inte med i kodtäckningsrapporten och varför?
Assistenten kan komma med följdfrågor men grundtanken är att ni med redovisningen visar att det är ni som skrivit koden och att ni förstår vad ni har gjort.

Redovisning på distans

Om ni inte skulle ha möjlighet att närvara för redovisning kan ni även välja att spela in en screencast på ca 5-10 minuter där ni kort besvarar frågorna ovan och visar er kod. Ladda då upp screencasten och mejla en länk till robin.keskisarkka@liu.se.

Inlämning

  1. Lägg upp er och kod andra relevanta filer för labben till ert tilldelade repo på gitlab.liu.se.
  2. Skapa en tag (använd formatet lab2-v.1.x) för er inlämning. Vid rättning är det alltid den senast taggade versionen för labben som rättas.
Rekommenderad deadline: 19:e september 2023 23:59 CEST

Specifikation 1

Funktion Anrop Metod Parametertyp Exempel Returvärde
Spara meddelanden /messages POST application/json { message: "My tweet" } HTTP 200
Markera som läst/oläst /messages/{id} PATCH application/json { read: false } HTTP 200
Hämta meddelande /messages/{id} GET application/json
Hämta alla meddelande /messages GET application/json

Specifikation 2

Funktion Anrop Metod Parametertyp Exempel Returvärde
Spara meddelande /save POST application/json { message: "My tweet" } HTTP 200
Markera som läst/oläst /flag POST application/json { id: 1234, read: false } HTTP 200
Hämta meddelande /get GET URL-parameter ?id=1234 application/json
Hämta alla meddelande /getall GET application/json

Sidansvarig: Robin Keskisärkkä
Senast uppdaterad: 2023-08-15