Understrukna ord finns i lektionsordlistan. Tryck på ett ord för att se alla översättningar. Lägg till eller redigera ord i messages/glossary.json (alla språknycklar du lägger till visas i rutan).
Coding, debugging, and design
Explaining code and architecture
Hela systemet är uppbyggt kring en mikrotjänstarkitektur.
Vår frontend kommunicerar med backend uteslutande via ett REST API.
Vi använder oss av MVC-mönstret för att separera logik från vy.
All affärslogik ligger samlad i service-lagret, helt skild från kontrollerna.
Vi har valt en händelsestyrd arkitektur för att göra systemet mer frikopplat.
Klienten skickar en förfrågan, och servern svarar med JSON.
Vi använder ett Singleton-mönster här för att spara på resurser.
Det här lagret ansvarar enbart för att prata med databasen.
Vi har en gateway framför våra API:er som hanterar all autentisering.
Datan flödar alltid i en riktning, från förälder ner till barnkomponenterna.
Vi använder en relationsdatabas för användardata, och en NoSQL-databas för loggar.
Det här biblioteket fungerar som en adapter mot det externa systemet.
Vi försöker bygga våra tjänster så tillståndslösa (stateless) som möjligt.
Den här modulen är helt isolerad och kan bytas ut utan att påverka resten av koden.
Vi implementerar Dependency Injection för att göra koden lättare att testa.
Systemet använder asynkrona köer för att hantera de tunga rapporterna.
När användaren klickar sparas datan först i en lokal cache.
Koden är uppdelad i mindre och mer hanterbara domäner.
Vi har en lastbalanserare som fördelar trafiken mellan de olika servrarna.
Autentiseringen sker via JWT-tokens som skickas med varje anrop.
Vi använder WebSocket för att kunna pusha uppdateringar i realtid till användaren.
Modellen representerar exakt hur datan ser ut i databasen.
Vi har abstraherat bort databaslogiken genom att använda ett ORM-verktyg.
Det här designmönstret gör det väldigt enkelt att lägga till nya betalningsmetoder.
Hela systemet är designat för att kunna skala upp automatiskt vid hög belastning.
Vi kör en uppgift i bakgrunden varje natt som rensar upp gamla rader i databasen.
Den här klassen har bara ett enda ansvarsområde (Single Responsibility).
Vår arkitektur bygger på att separera läsning och skrivning (CQRS).
Vi använder strategi-mönstret för att dynamiskt välja rätt algoritm.
Gränssnittet uppdateras asynkront utan att hela sidan behöver laddas om.
Varje tjänst har sin helt egna databas för att undvika beroenden.
Vi utnyttjar en CDN för att leverera statiska tillgångar som bilder och CSS mycket snabbare.
Den här funktionen fungerar som en ren funktion – samma input ger alltid samma output.
Vi paketerar koden i moduler för att kunna återanvända den i flera projekt.
Observer-mönstret används här för att lyssna på när objektet ändras.
Systemet är byggt för att vara modulärt och mycket flexibelt för framtida krav.
Vi har ett lager för rate-limiting för att skydda API:et från överbelastning.
Databasen är partitionerad för att kunna hantera de enorma datamängderna.
All data krypteras innan den lagras (encryption at rest).
Vi bygger arkitekturen med molnet i åtanke, så kallat cloud-native.
Det här är vår huvudkontroller, den dirigerar trafiken till rätt plats.
Vi använder Factory-mönstret för att instansiera komplicerade objekt.
Applikationen har en offline-first-arkitektur för mobila användare.
Vi separerar konfiguration från kod med hjälp av miljövariabler.
Koden förlitar sig mycket på generiska typer för att vara typsäker och flexibel.
Vi använder en API-gateway för att slå ihop anrop till flera olika mikrotjänster.
För att undvika race conditions låser vi raden i databasen under uppdateringen.
Det här lagret kartlägger databasklasserna mot de modeller som skickas till klienten.
Vår strategi för cache-invaliditet bygger på tidsbegränsning (TTL).
Arkitekturen är designad för att vara extremt feltolerant och pålitlig.
