Struktur

Der har været nogle udfordringer i forhold til hvordan at strukturen skal bygges op, da at backend og frontend helst skulle være ret hurtige.
Problemet ligger så i at jeg ikke er sikker på om jeg vil dele projektet op i 3 forskellige projekter, her i Starlite, React og Python.
Jeg havde også regnet med at wrap React i en NextJS app, så at der er mulighed for at bruge noget serverside rendering, hvis nødvendigt.

Og så er der den mulighed at man kunne lægge alt snak med databasen over i NextJS appen, så at man ikke behøver at have en Starlite API til at køre i baggrunden.
Da at jeg har arbejdet en del med NextJS i forvejen, sammen med noget tRPC og Drizzle-ORM, så virker det helt klart oplagt at vælge NextJS som backend operatør.
Dette har været en del af mine udfordringer i forhold til hvordan at backend skal laves.

Jeg har prøvet at lave en skitse af hvad de forskellige ting skal lave i Excalidraw:

Skitse af NextJS + Python Skitse af NextJS + Python

NextJS

Her er det så meningen at NextJS skal give klienten en Frontend, så at brugerne kan få det de skal have, i stedet for en statisk hjemmeside.
I NextJS laget, ligger der også det man kalder Authentication, altså - Log ind, log ud, og log ind med diverse tredjeparts oauth.
Ikke nok med det, så skal NextJS også stå for at have basiske API kald, så at man kan få informationer fra en database, i form af tRPC der så bruger Drizzle-ORM.

Python

Pythons primære job ligger i at tjekke imod TooGoodToGo’s API hele tiden. Det første er at når nogen logger ind på vores hjemmeside med deres email, så skal vi hente et polling id fra TooGoodToGo API’en, som bliver brugt til at tjekke om man har verificeret login på TooGoodToGo - For at kunne komme ind og se folks favoritter etc. skal vi bruge en access_token samt en refresh_token.
access_token bliver brugt til at tilgå deres API på brugerens vegne, for at kunne finde ud af hvad deres favoritter er.
refresh_token er essentielt bare en token man bruger til at få en ny access_token når at den er udløbet.

Alternativ måde at lave det med polling på Alternativ måde at lave det med polling på
I skitsen ovenover, er der lavet så at man ikke behøver Python som middle-man, da at der så ikke er brug for at der bliver sendt et request til TooGoodToGo API’en hvert minut.
Det andet at Python skal, det er at se om der er kommet nye vare ved de steder der er blevet sat notifikationer op til.
Altså, i grove træk så skal den bruge en access_token til at se de forskellige butikkers inventar, og se om de har fået nye siden sidst der blev tjekket.
Hvis at inventaren er gået ned ad, skal den ikke gøre noget, men hvis den er gået op siden sidste tjek, skal den sende en notifikation til dem som har sat notifikationer op til den specifikke butik.

Design

Designet er så småt kommet fra start, med et farveskema som skal bruges, smat nogle af elementerne.

TooGoodToMe Farveskema TooGoodToMe Farveskema
Til designet, er der blevet taget en god del inspiration fra TooGoodToGo appen, men med et originalt twist, for at adskille os fra TooGoodToGo.

Den store udfordring i forhold til Design, har helt klart været at det skal være originalt, intuitivt og nemt at navigere for brugerne.

Nogle design elementer fra TooGoodToMe Nogle design elementer fra TooGoodToMe
Da at vi skal kunne vise nogle butikker inden for en hvis rækkevidde fra et sted, skal der være en slags “grid”, om man så må sige - til at vise brugeren, hvilke butikker der er i nærheden, samt hvad de har af ting man kan købe fra dem.

Starlite

Jeg vil komme til at bruge Starlite til dette projekt, da at det er et af de hurtigste python frameworks til udvikling af API.

Flutter

Eh?