receptakuten-backend

Backenden är utvecklad enligt principerna för Clean Architecture i tankarna men följer inte fullt ut men försöker hålla ansvar och beroenden tydliga och separerade mellan olika lager (Bytte namn från Meal Menu till Receptakuten när projektet närmade sig sitt slut).

API-lagret fungerar som systemets yttersta gränssnitt och ansvarar för routing, autentisering, middleware, konfiguration av tjänster och mottagning av inkommande förfrågningar. Controllers innehåller minimalt med logik och fungerar främst som ett lager för validering och transformering av inkommande data.

När en förfrågan når API:t valideras den först genom särskilda Request Models med egna regler för datavalidering. Därefter omvandlas informationen till DTO-objekt som skickas vidare till applikationslagret.

Applikationslagret innehåller all affärslogik och är systemets kärna.Här finns tjänster, DTO:er, entiteter, regler och processer som beskriver hur verksamheten fungerar.Lagret är medvetet byggt utan beroenden till databaser, externa tjänster eller tekniska implementationer, vilket gör det enkelt att testa och vidareutveckla.

Infrastructure-lagret ansvarar för den faktiska kommunikationen med databasen och externa system. Här finns repositories, Entity Framework-konfigurationer, filhantering och integrationer mot externa tjänster såsom Azure Communication Services. Genom att använda interfaces mellan lagren kan implementationer bytas ut utan att affärslogiken påverkas.

Databas och datamodell

Databasen är utvecklad enligt en Code First-strategi med Entity Framework Core. Datamodellen definieras i kod och migreras därefter automatiskt till PostgreSQL genom migrations.

Databasen innehåller ett flertal relationer mellan användare, grupper, recept, matscheman och inköpslistor. Denna struktur gör det möjligt att hantera både personliga receptsamlingar och gruppbaserade funktioner på ett konsekvent sätt. Ett exempel på relationer nedan:

För att förbättra användarupplevelsen redan från start används seedning av data. Exempelrecept och grundläggande enheter för ingredienshantering skapas automatiskt när systemet initialiseras.

Säkerhet

Säkerhet har varit en central del av projektets design.

Autentisering sker genom ASP.NET Identity tillsammans med JWT-baserad autentisering. Access tokens och refresh tokens lagras i HttpOnly-cookies för att minska risken för exponering via klientskript.

Systemet använder flera säkerhetslager för att skydda API:t, bland annat:

JWT Authentication
Refresh Tokens
Cross-Site Scripting
Rate Limiting
Inputvalidering
Roll- och behörighetskontroller

Utöver klientbaserade begränsningar verifieras samtliga rättigheter även på serversidan för att säkerställa att obehöriga användare inte kan kringgå systemets regler genom manipulerade anrop.

För att aktivera nya konton krävs e-postverifiering och samma mekanism används vid glömt lösenord.

Realtidsfunktioner

För funktioner som kräver omedelbar återkoppling används Server-Sent Events (SSE). Ett exempel är gruppinbjudningar där mottagaren får uppdateringar direkt från servern utan att klienten behöver skicka återkommande förfrågningar.

Detta ger snabbare återkoppling samtidigt som belastningen på API:t minskar jämfört med traditionell polling.

Bildhantering

Användaruppladdade bilder bearbetas på serversidan med hjälp av ImageMagick via Magick.NET. Där kontroll av accepterade bildtypr kontrolleras, storlek osv

Vid uppladdning genomförs konvertering och storlek/kvallitets optimering för att minska lagringsutrymme och förbättra laddningstider. Bilderna lagras därefter på servern och kopplas till respektive recept. Nedan kan man se att Clean Code mönster följs med flera små metoder används för att ge klarare förståelse när man läser koden, detta upprepas över hela projektet.

Automatisering och bakgrundsjobb

Systemet använder Quartz.NET för schemalagda bakgrundsjobb som körs oberoende av användaraktivitet.

Dessa jobb används bland annat för att:

Hantera avslutade matscheman
Rensa utgångna refresh tokens
Identifiera inaktiva användare
Ta bort konton som aldrig aktiverats

Dessa jobb configureras med hjälp av nycklar och triggers där man sedan anger när de ska köras, Här kan ni se ett exempel på ett av dess jobb:

Genom att flytta denna typ av arbete till separata processer kan API:t fokusera på användarrelaterade förfrågningar samtidigt som återkommande underhåll sker automatiskt.

Loggning och felhantering

För övervakning och felsökning används Serilog med stöd för både konsolloggning och filbaserad loggning.

Systemet använder en central Global Exception Handler som fångar upp oväntade fel och returnerar konsekventa felmeddelanden till klienten. Detta minskar mängden duplicerad felhantering i applikationen och förenklar felsökning.

I särskilda situationer där återhämtning är möjlig används riktade try/catch-block för att hantera specifika undantag,exempelvis vid filhantering och borttagning av resurser från servern.