Struktur¶

Filstruktur¶

Strukturen för en backend-tjänst. Exempel på dessa är minilith och fed-auth.

• schema: definitionen av schemat, se denna guiden
• migrations: .sql-filer som genereras av schema som ändrar schemat på databasen när schemat i schema uppdateras.
• src/main.rs: väldigt standard, startar bara en server med endpointen från lib.rs
• src/lib.rs: här skapas endpointen, alltså vilka tjänster som är tillgängliga i APIet
• src/context.rs: här definieras och laddas all data som behövs av alla handlers (alltså de funktioner som hanterar HTTP requests). T.ex. skapas kopplingen till databasen här. Nycklar laddas från miljön etc.
• src/<..>.rs: andra filer i src kan innehålla hjälpfunktioner för t.ex. cookies, men främst innehåller de routes (som är ett struct som heter *Router, derivear Clone) och #[OpenAPI]-impl-block som definierar alla handlers.
• tests/lib.rs: hjälpfunktioner för tester, ofta innehållande en funktion för att få en test-klient
• tests/<..>.rs olika integration-tests.
• .env.example: ett exempel på hur ens .env-fil kan se ut, med dummy-nycklar etc. Kopiera denna till .env före du börjar utveckla
• .env: filen med alla miljövariabler. Den ignoreras av git, så om du lägger till en miljövariabel kom ihåg att lägga till den i .env.example också!

Namngivning¶

• Om en handler tar en body, bör denna heta <Handler's name>Request.
• Handlern's retur-typ bör vara Result<..., <Handler's name>Error>.
• <Handler's name>Error är ett enum av fel (se exempeln).
• Om en handler returnerar data i ett struct borde detta heta <Handler's name>Response.

Extras¶

Alla Route objekt bör implementera Deref<Target = Context>. Detta gör så att man kan skriva t.ex. &self.db i en handler, istället för &self.context.db.

Föredra gärna sqlx::query! över sqlx::query_as! och en struct för att returnera data till klienten. Detta då datan väldigt sällan stämmer överrens 1:1 med databasen (t.ex. användardata är kryterad, där kan finnas listor av delobjekt som är separata SQL queries etc).