Sammanfattning - "Stå-upp"-vlogg (2024), del 3

Tredje och sista vloggen i kursvecka 16-19, inför kursens sista vecka.

Återkoppling på realtidsapplikationen B2

Det vanliga upplägget är att klienten laddar sidan från servern, som hämtar alla issues och renderar en vy, och att klienten sedan kopplar upp en WebSocket. När GitLab skickar en webhook tar servern emot och verifierar den och skickar informationen vidare till klienterna över WebSocket-anslutningen.

Skicka data, inte “ladda om dig”. Att via WebSocket-anslutningen bara be klienten ladda om sidan faller inom kraven, men är inte som det är tänkt. Anslutningen kan själv bära den data som behövs för att hålla klienten i synk.
Uppdateringar från klienten. Postar klienten till exempel “stäng issue” till servern och får en omrenderad vy tillbaka, kommer GitLab också att skicka en webhook, och klienten får samma information två gånger. Fler har i år i stället skickat meddelandet över WebSocket-anslutningen till servern, en slags WebSocket-routing. Det är en godtagbar lösning. Det kan ge märkbart lång svarstid, vilket kan lösas med optimistisk uppdatering, men det är mer avancerat än vad kursen kräver.
Återanvänd webbkomponenter. En issue är ett utmärkt exempel på något som kan vara en webbkomponent. Det är inget krav, men en inlämning fick guldstjärna för det.

B3: flera tjänster som ska hållas i synk

När klienten uppdaterar en resurs via resource-tjänsten uppdaterar den i sin tur bilden i image-tjänsten. Egentligen ska antingen hela uppdateringen gå igenom eller ingenting, vilket kräver återställningskod om något steg misslyckas. Det finns inget krav på det, så börja med att förutsätta att allt går bra, och lägg gärna en TODO i koden. Den största risken är att den externa image-tjänsten inte svarar. Uppdatera därför image-tjänsten först och den egna databasen sedan, så kan du svara med ett fel utan att behöva återställa något om det första steget misslyckas.

Egna id:n. Använd inte image-tjänstens id som id i resource-tjänsten, utan spara det i ett eget fält. Då står det dig fritt att välja databashanterare oberoende av hur image-tjänsten lagrar sin data.
Bara egna resurser. En användare ska bara kunna se och ändra sina egna resurser via resource-tjänsten.
nginx-konfigurationen. De extra proxy_set_header-raderna i guiden till servern behövdes för WebSocket-anslutningen i B2. För B3 räcker nginx-exemplen i uppgiftens issues 10 och 11.