Min första professionella SaaS app och många frågor. Upplägg, kostnad?

Användarna av din applikation ska aldrig skriva direkt till databasen. Du skriver en backend som är den enda som skriver till databasen.

Tror personen gissar att du har en app för att rapportera arbetstid. D.v.s. tidsskrivning.

1) Jag skulle använt en Key/Value store istället, också kallat Document DB, eller Table Storage, möjligen Firebase, se brasklapp nedan. Serverless är att föredra i många fall.

2) Det räcker att backenden vet vad den gör. Om du kör Firebase som databärare till din app har den inbyggd "data-per-användare" grejer och lite annat smått och gott som är trevligt i app-världen, men jag är osäker på hur bra den är om man skulle vilja lägga den bakom en backend, då en stor del av enkelheten att använda med Firebase är att den har utmärkt SDK för att leverera push-liknande funktionalitet. Är också osäker på huruvida den stödjer ordentliga backup-möjligheter utifall du skulle göra ett misstag.

3) Spelar ingen superstor roll vad du skriver i för språk, men Python är nog lite mindre lämpligt annat än som en proof of concept, det skalar rätt illa. Java eller Node backend är nog lämpligast då det finns mest "off-the-shelf" grejer som är klara och redo att agera Web API för de ekosystemen.

4) Redan 50 anrop per sekund är väldigt massivt. Jag tror inte du kommer ha i närheten av det. 1000 anrop per sekund skulle kosta miljoner per år. Om du bygger dina grejer i valfritt moln, kan du skala upp och ut vid behov, börja med gratisnivåerna på allt som går.

Jag tycker också volymen verkar… intressant. 50 anrop/s motsvarar ju 1 anrop per minut och användare (30x100 användare). Jag fick det till 1,44 miljoner anrop per dag på en åtta timmars arbetsdag. Om det ska skapas en databasrad/dokument per anrop så blir det snabbt intressant att ha bra index.

Jag skulle också i ett tidigt skede titta på en lösning för att inte dra för mycket batteri ur mobilerna om appen faktiskt ska vara aktiv så mycket.

Det känns som om mycket av valen kring säkerhet i den här lösningen kommer att hänga på kontoadministrationen. Vem skapar konton? Vem kopplar ett konto till en viss kundorganisation? (Det styr ju i förlängningen fakturering) Användningsfallen behöver komma före tekniken på det området, men det kanske bara är otydligt i trådstarten.

Passande nog så har jag nyss påbörjat kurserna Databaser och PHP Programmering i min Webbutvecklingsutbildning så mina svar kan skilja idag och om cirka 7 veckor!

Du bör börja med en Verksamhetsbeskrivning för att ta fram en "Entitets-relationsmodell" för att få ett "hum" om vad som (inte) ska ingå i databasen. Databasen bör utgå från vad verksamheten anser sig behöva data om.

Rörande säkerheten så låter det som "Integritetsvillkor" för att bestämma vem, vilka, var, när och hur de (inte) ska få åtkomst till olika Tabell(er) i olika Databas(er) samt datatypskontroller vid inmatning av användare.

Möjligen kanske du vill implementera så att inloggningsuppgifterna också är kopplade till arbetstelefonernas simkortsnummer för att öka säkerheten? (Givetvis lite extra teknisk support som då krävs när arbetstelefon måste bytas ut)

Är det verkligen så många anrop per sekund? Hur lyckas de projektanställda att uppnå sådana "manuella anrop"? Måste de skriva ned varje fotsteg de tar?

Du kan ju alltid kontakta diverse svenska webb- och/eller serverhotell och ge dem en ungefärlig anropssiffra per sekund av så många personer per sekund och då få en ungefärlig månadskostnad tänker jag?

Mvh,
WKL.

Av ren nyfikenhet så undrar jag vad det är som gör Python dåligt att skala upp med? Syftar du då också på Python som Backend-lösning som talar med databas(er) och klient(er)?

Det jag reagerar på är det här. Du säger att:

• Det ska sparas några KB data för varje anställd varje dag.

• Det ska sparas i JSON.

• Du förväntar dig typ ett anrop per anställd per minut, om jag förstår saken rätt.

Det här går inte ihop för mig. Varför i JSON? Ska du spara typ 500 JSON-poster per anställd per dag, och sedan aggregera det? Eller ska du aggregera datat i den JSON du sparar? Varför lagra JSON över huvud taget?

Jag förstår att du är vag när du beskriver din idé, men som det är nu är problemet för dåligt beskrivet för att du ska få ett vettigt svar.

Om ett anrop per minut/anställd, varför inte cache:a i appen?
Om det görs manuellt idag så borde även en fördröjning på 15 minuter innan datan syns i databasen vara tillräckligt.

Vilka resurser använder du på telefonen? Appen ska ju skicka något varje gång, den data som den skicka är det positionsdata eller annan data som kräver att andra funktioner används på telefonen (GPS, Bluetooth etc)?
Har du tänkt på hur mycket batteri appen kommer att konsumera med både att den ska skicka data ofta och hur denna data samlas ihop?

Sedan GDPR. Du kommer att behöva veta hur detta gäller för dig. Gör detta redan i början så att du vet vad du måste hålla reda på under utvecklingen av din lösning. (Vilken information som sparas och varför till exempel.)
Sedan behöver du en funktion som också raderar data enligt GDPR, enkelt i två nivåer (du ser säkert detta när du läser på själv). Den ena är när användaren ber om att data ska raderas, den andra är när data ska raderas för att den inte behövs.
Skillnaden är att när en användare ber om att data ska raderas så innebär det inte att data som omfattas av andra lagar ska raderas, till exempel i ett lönesystem så styr bokföringslagen hur länge data ska sparas. Men det kan finnas annan data som inte behövs enligt bokföringslagen (i detta exempel) som isf ska raderas om användaren ber om det.

När jag läste din OP kom jag tänka på ett system som används för tidsredovisning av en städfirma. Där de anställda checkar in på varje ställe där de ska jobba och checkar ut. Det finns geo-funktioner i systemet så att de inte kan checkan in om de faktiskt inte är på plats. Vet inte om det finns automation (nu) för in/ut checkning baserat på geo lokation.

Nu vet jag ju inte alls vilka kunder det rör sig om och så.

Men en tanke är väl att, istället för att du ska generera nycklar, bygga auth med t.ex. Azure AD (utgår då från att dina kunder använder Microsoft 365). Låt de skapa projekt själva, tracka hur många projekt de har i nån admin-vy och ta betalt per aktivt projekt eller annan lämplig modell. Med Azure AD och Graph API kan de sedan själva lägga till andra användare till projekten, förutsatt att användare finns i samma tenant.

Om data ändå ska skickas som JSON, varför inte spara som JSON direkt ned i t.ex. CosmosDB (dokumentdabas i Azure)?

Nu propagerar jag mycket för Azure här, men det du beskriver känns som att det överlag kan lösas med Azure Funtions som skriver/läser från en CosmosDB och så har du dina front ends i React/React Native.

Behöver du mer avancerad backend så tycker jag absolut att du ska undvika Python då alla projekt jag varit involverade med som har Python backend alltid slutar med att den byts ut mot något annat (.NET/C#/whatever).

Som andra har nämnt så gäller såklart GDPR. Jag föreslår att du ändå tar en del höjd för GDPR redan nu. Du är skyldig att följa GDPR och hantera radering/anonymisering av data.