Mjukvaruarkitektur - 1DV611/effect-reklambyra GitHub Wiki
Övergripande struktur (baserat på den tekniska dokumentationen)

Bilden ovan visar de olika komponenterna i systemet. Det är en klassisk client-server modell, där klienten och servern är så löst kopplade som möjligt.
Förkunskaper
Det här projektet kräver kunskaper inom Node.js, JavaScript, Bootstrap.js, och grundläggande kunskaper inom MongoDB. För att förstå API:erna behövs dokumentationen för varje API studeras.
Dokumentationen använder sig av sekvens diagram.
Server
Serverns jobb är att kommunicera med de olika API:erna, plocka ut relevant data och skicka den till klienten, möjligen spara en rapport i databasen för att kunna jämföra datan senare. Databasen är MongoDB som kommer hanteras med Robomongo. Det är också servern som kommunicerar med den externa tjänsten auth0's autentiseringsserver för att sköta inloggningen till applikationen.
Serven använder Express.js ramverket som grund för routning bland annat.
Databasstrukturen hittar ni här.
Klient
Klientdelen är såklart det användarna ser när de använder systemet. Det sköter användargränssnittet och använder JavaScript, HTML, CSS, och Bootstrap.js för att rendera sidorna. När användaren loggat in kan de välja vad de vill ha ut från API:erna. Sedan använder klienten API-datan, som hämtas och skickas till klienten av servern, för att göra en rapport i form av PDF-fil till användaren med hjälp av ett bibliotek/ramverk.
Chart.js kommer att användas för att rendera snygga tabeller och av API-datan.
Filstruktur
Vi siktar på en någorlunda lös koppling mellan servern och klienten, därför är filer som rör server och klient delar separerade i filstrukturen.
Filerna är logiskt separerade med beskrivande namn.
|--- client
|-- css
|-- js
|--- routes
|--- server
|-- APIs
|-- databaseOperations
|-- app.js
|--- tests
|--- views
|-- layouts
|-- partials
Klientkoden som css & klientjavascripten ligger under /client,
Express.js routrarna ligger under /routes,
app.js som startar servern ligger under /server,
testkod ligger under /tests,
och handlebarstemplates/renderingsfiler ligger under /views.
Arkitekturellt signifikanta krav
Dessa kraven valdes eftersom det är grunden på applikationen och tillsammans går dem igenom alla delar av arkitekturen/strukturen. Inloggningen börjar på klienten där användaruppgifter fylls i som sedan går vidare till authentiseringsservern.
Rapporten börjar också på klienten, sen tar servern ut datan från de sociala mediernas API som sparas i databasen och skickas till klienten för att visa användaren i en rapport.
Implementation
Krav ID 1 - Inloggning
I mappen views finns handlebars partials för varje sida, inklusive login, som sedan serveras till klienten av servern. Detta görs i mappen routes där start.js hanterar inloggningen. Login-informationen skickas till authentiseringsservern auth0 som omdirigerar (redirect) användaren till /callback, som också hanteras av start.js. Där finns authentiseringsdatan i parametern req. Om inloggningen gick bra omdirigeras användaren till /user som hanteras av user.js.
Nedan är ett sekvensdiagram som beskriver detta. Eftersom sekvensdiagram är mer inriktat mot objektorienterade språk så består diagrammen av komponenterna istället för objekt. Det är för att kunna ge en övergripande vy av systemet.
'Client' är webbläsaren och diagrammet börjar när användaren tryckt på login knappen.

Diagrammet när inloggning misslyckas är till största del detsamma. Skillnaden är att användaren omdirigeras till en "felsida" istället för /user.

Krav ID 8 - Rapport
Efter inloggning kan användaren välja att skapa en rapport. Från /user/dashboard kan användaren välja månad, år, samt vilka API:er som ska vara med och sedan trycka på Preview-knappen, vilket tar användaren till /user/report/[month]/[year] som hanteras av user.js. Där tas API-datan ut från databasen och skickas tillbaka till klienten. Därefter kan användaren välja 'Create Report' för att skapa rapporten.
Nedan är ett sekvensdiagram för detta. 'Client' är webbläsaren och diagrammet börjar när användaren är inloggad och trycker på Preview-knappen.

Vidareutveckling
Koden för varje API är separerade i filer placerade i server/APIs. Dessa filer kallas sedan av callAPIs.js, där det kontrolleras vilka API:er som ska kallas.
Alla API:er skiljer sig åt när det gäller att få ut data så det är bäst att undersöka dokumentationen för varje API.
När ett nytt API ska stödjas behövs alltså callAPIs.js uppdateras, en ny fil som kommunicerar med de nya API:et baserat på deras dokumentation ska läggas i server/APIs. Databasen måste också uppdateras för att stödja de nya API:et, vilket görs i databasscheman i server/databaseOperations/schemas. Det är också viktigt att beroende på om API:et kräver authentisering så behövs det göras en länk för användare att trycka på för bevilja att applikationen får tillgång till kontots uppgifter för de API:et.