Short system design report - sios13/github-dashboard GitHub Wiki
Short system design report
I den här rapporten ska jag presentera min system design för att skapa en webbapplikation “Github Dashboard”. I webbapplikationen ska man kunna se organisationer och prenumerera och bli meddelad om olika händelser.
Revisioner
25-02-2018 - Första versionen
13-03-2018 - Uppdaterade flöden och några småkorrigeringar.
Arkitektur
I mitt val av arkitektur för att skapa denna webbapplikation övervägde jag några alternativ.
Flerlagerstruktur
+ tydlig uppdelning mellan logik och presentation
− komplexitet
Micro services
+ när en micro service inte fungerar kan webbplatsen fortfarande fungera som vanligt
− kan vara långsamt (fördröjning när micro services ska prata med varandra)
Serverless
+ enkelt att komma igång och behöver inte hantera serverinställningar + relativt billigt (betala bara för tiden som en funktion körs)
− relativt outvecklad arkitektur och många tjänster är i ”beta”
Jag har valt att använda mig av arkitekturen Serverless. Jag ser applikationen som ska skapas som relativt liten och därför tror jag att det hade passat bra att skapa några få funktioner i en molntjänst som agerar som server. Jag tror inte webbapplikationen som ska skapas är tillräckligt omfattande för att motivera en arkitektur med flera micro services eller att skapa en större och mer komplex monolit i en flerlagerstruktur.
Server
På servern kommer jag att skapa funktioner som görs synliga utåt av ett API. Det finns flera tjänster som tillhandahåller tjänsten att bygga serverless-funktioner.
Amazon Web Services
+ har stöd för javascript, nodejs + är inte i ”beta” + erbjuder databas
− man kan inte installera dependencies genom npm (manuell uppladdning av zip-filer istället)
Google Cloud Functions
+ har stöd för javascript, nodejs + kan installera dependencies genom npm + erbjuder databas
− är i ”beta”
Överlag erbjuder Amazon Web Services och Google Cloud Functions relativt lika funktionalitet. Jag har valt att använda Amazon Web Services (AWS) eftersom denna tjänst inte är i ”beta” och är förhoppningsvis därför en mer stabilare och pålitligare tjänst. För att kunna skicka notifikationer planerar jag spara användarnamn, organisationer och typer av notifikationer i en databas (databas erbjuds av både Amazon Web Services och Google Cloud Functions).
Klient
Eftersom servern kommer fungera som ett API anser jag att det skulle passa bra att skapa en ”single page application” (SPA). Webbapplikationen kommer att kommunicera med APIet och anpassa sitt innehåll efter de JSON-filer som tillhandahålls av servern.
Vid val av klientramverk resonerade jag på följande sätt.
Inget ramverk
+ ingen onödig overhead
− ingen automatisk omrendering
Angular
+ Robust och utvecklas av Google
− relativt hög inlärningskurva − är ett ramverk som är bättre lämpat för större/full-stack applikationer
React
+ relativt enkelt att komma igång + bra för att skapa användargränssnitt (fungerar som ett bibliotek) + kraftfull renderingsfunktion
− inte lika stort community som Angular
Jag har valt att använda React. Jämfört med Angular verkar React bättre anpassat till att enbart användas till vyn, vilket jag tror är en fördel till applikationen som ska skapas.
Flöden
Webbapplikationen kommer att ha flera olika typer av flöden. Jag har identifierat tre typer av flöden som jag presenterar nedan.
Autentisering
För att kunna läsa en användares organisationer från GitHub måste användaren autentisera sig mot GitHub och få en access token. Flödet för hur detta planeras gå till beskrivs i bilden nedan.
Uppdatering 13-03-2018
Efter att ha implementerat applikationen kan jag konstatera att flödet för att autentisera ser i stort sett likadant ut. Nedan följer en uppdaterad bild.
Huvudflöde
När autentiseringen har skett kan en användare använda sin access_token för att hämta sina organisationer. Bilden nedan visar flödet för hur detta är tänkt att gå till. Samma flöde som visas i bilden kan även användas för att hämta annan information från Github, inte bara organisationer.
Uppdatering 13-03-2018
Under utvecklingen av applikationen valde jag att inte låta klienten prata med Github genom servern, istället pratar klienten direkt med Github. Jag valde att göra denna förändring eftersom (1) det minskar fördröjningen som det innebär när servern är en mellanhand och (2) det minskar kostnaden för servern. Med denna förändring blir alltså klienten lite “smartare” och servern lite “dummare”.
Se uppdaterad bild nedan. Notera också att bilden är mer generell och beskriver de flesta “huvudflöden” som finns i applikationen, jämfört med föregående bild som enbart beskriver att hämta organisationer.
Notifikationer (Webhooks, WebSocket)
Följande bild visar två flöden. Röd färg visar flödet för att spara notifikationsinställningar och blå färg visar flödet för hur Webhooks används för att skicka notifikationer till klient, messenger och slack.
Uppdatering 13-03-2018
Efter att applikationen har implementerats ser flöden för notifikationer i stort sett likadant ut. Den stora skillnaden är att notifikationer nu sköts av Amazon Web Services genom email (Simple Email Service), istället för Messenger/Slack. Nedan följer en uppdaterad bild.
Sedan sist har jag också gjort förändring i hur WebSockets hanteras. Lambda-funktioner har inget stöd för WebSockets, istället skapade jag en egen socket-server som jag kör på en egen port.
