Motivering för initiala valet av teknologier¶
Just nu är vi i månad två av design & utvecklingsfasen. Före denna började skedde ett stort arbete kring att hitta teknologier som alla var överens nog om.
Alla rubriker är teknologval som under dem har punkter från beslutsgrunden.
Rust¶
Underhållbarhet¶
Rust valdes då den har ett par fördelar över "lättare" språk, som Go eller Python eller Javascript.
- det är svårare att göra fel, kompilatorn kommer klaga på dig
- väldigt få fel dyker upp i produktion (om det inte är logikbuggar)
- om man får problem är kompilatorns meddelande ofta väldigt bra
- det finns en skill-tröskel till rust, vilket gör att utvecklare som inte hållit på ett tag avskräckas
- detta ses som både en bra och dålig sak. Å ena sidan filtrerar vi ut talang, å andra sidan är det mindre chans att någon med mindre kunskap pillar på den väldigt känsliga delen av verksamheten som är backenden
- där finns talang från både E och F med Rust. Go fanns bara från D.
Där finns klart argument om att språket inte spelar någon roll sålänge koden som är skriven i den är bra. Och det är sant. Men genom att välja ett språk som ligger i linje med våra mål kan språket i sig agera polis. Rust lägger över en stor del av bördan från reviewern till kompilatorn.
Prestanda¶
Rust is blazingly fast. Ok jokes over så är rust väldigt snabbt sålänge man inte är dummis med algoritmer och datastrukturer.
Svelte¶
Underhållbarhet¶
- samma för android & web och ios
- både E och D har sina hemsidor skrivna i det så det är nästa garanterat att där finns kvar kompetens
- det går att med Capacitor implementera liquid glass & få en native feel. Detta är lätt att slopa om underhållsbördan blir för stor.
Postgres¶
Underhållbarhet¶
- ett väldigt standard system
- stödjer väldigt mycket på ett bra sätt
- det visade sig att deras ltree var väldigt bra för grupprepresentation
Prestanda¶
Postgres är snabbt också. Sen gäller det klart att designa kringliggande system så de inte är dumma och låser hela databasen konstant.
Poem¶
Underhållbarhet¶
- web frameworks uppdateras inte mycket, därför är valet av dem inte så avgörande
- att byta framework är mer att ändra formatet på funktions-decorators.
- poem hade bäst stöd för OpenAPI av rust web frameworksen. OpenAPI underlättar interfacet mellan frontend och backend avsevärt.
- relativt många nerladdningar så projektet kommer inte dö om 1 år
Prestanda¶
- poem gör inte något egentligen
- det kommer alltid finnas en reverse-proxy som hanterar HTTPS & HTTP/2 & HTTP/3 & compression åt oss. Därför behöver vi inte bry oss om prestanda i application-layer (och under).
SQLx¶
Jag (Erik) ville först ha Diesel och Åke SQLX. Åke kom dock med många bra argument för SQLX. Bland annat är att vi alltid vill se över & potentiellt ändra migrations vilket gör att Diesels automatiska migration generator är redundant. Dessutom är den inte superbra. Dessutom är det lättare att bara behöva lära sig SQL istället för SQL & Diesels speciella interfaces etc.