Idé bag projektet

Stil dig selv følgende spørgsmål: "Er det en god idé at et web framework supporterer mange databaser?".

Hos Wivvies er svaret: NEJ, da det betyder, at du er begrænset til database adgang baseret på laveste fællesnævner.

Vi syntes det er en skam, at der er udviklet kraftfulde databaser som Oracle, Microsoft SQL, PostgreSQL og MySQL, og så bliver deres funktioner og hastighed ikke udnyttet af ORM faciliteterne i diverse frameworks, der også skal understøtte SQLite, Microsoft Access og andre simplere database systemer.

Derfor besluttede Wivvies sig for at lave et python framework, hvor udgangspunktet var at udnytte PostgreSQL til denne fremragende databases fulde potentiale. Dette er i forhold til variabeltyper, stored procedures og triggers i databasen, direkte JSON formatering i SQL forespørgsler, sikkerhedsopsætning med brugergrupper på database niveau og en række andre PostgreSQL specifikke "super funktioner".

Vores backend er et "API monster", med hastigheder der slår traditionelle framework/ORMs som django og flask/SQLAlchemy med flere længder - ikke en 30-40% men i mange tilfælde 100-1000% forbedringer. Vores hemmelige våben er logik flyttet ned i stored procedures på database niveau i stedet for logik i web framework, kombineret med komplekse forespørgsler, der danner svarerne til front-end i JSON allerede på database niveau i stedet for at skulle gennem en serializer på framework niveau.

Vi har bygget dette framework ovenpå FastAPI, som også er python baseret, men hvor en stor del af de underliggende biblioteker er skrevet i C og dermed optimeret kraftigt.

Vi er klar over, at logik i flere lag bliver mere kompleks for programmører, og derfor danner vi det meste af koden til dig direkte via en kodegenerator.

Manifester og kodegenerering

Hos Wivvies er vi dovne - vi ønsker at definere så få ting som muligt i en kravsspecifikation, og vi ønsker at ændringer kan laves ét sted fra - ikke noget med at skulle ind 10 steder i koden, fordi man har ændret noget på en indtastningsform.

Derfor benytter AG Manifest sig af netop manifester, hvor tabeller, kolonner, formler, relationer mellem tabeller, forespørgsler, sikkerhedsgrupper, valideringer m.v. er beskrevet ét sted, og dette sted bestemmer funktionaliteten for web applikationer, mobile applikationer, Windows/Mac/Linux applikationer og for den skyld også danner grundlaget for automatisk dokumentation.

For godt til at være sandt? Absolut ikke, vi benytter os af meget detaljerede manifester (informationer), der lagrer alt om databasen og applikationens virke, og derfra benytter vi os af kodegenerering til at danne de nødvendige: SQL scripts, Python kode og Flutter, der selvfølgelig hænger sammen.

Når du bruger en label eller et tekstfelt i AG Manifest generede applikationer, får de enkelte elementer informationer fra manifester om, hvordan de skal opføre sig fx. i forhold til formatering, placering på skærm, oversættelse mellem sprog, validering m.v.

Faktisk er en "sidegevinst" at disse manifester findes i databasen, og derfor skal mobil applikationer ikke gen-udsendes så mange gange (en besværlig og langsommelig proces) - i langt de fleste tilfælde kan ændringer foregå, ved blot at ændre i manifester på serveren. Oversættelser til mange sprog ligger også på serveren i stedet for en fil, der bliver "bagt" ind i mobil applikationen, så nye sprogversioner betyder ikke nye udgivelser af mobile apps.

Der er nu bare noget tilfredsstillende ved at definere ganske få linjers instruktion i nogle simple tekstfiler, og se tusinder af brugbare kodelinjer blive automatisk genereret - det er en fryd for "det dovne øje".

Hastighed

Vidste du, at når man kalder en forespørgsel i django, der bruger flere tabeller, så risikerer man at generere flere hundrede SQL sætninger, som bliver sendt mod databasen, hver gang man støder på denne forespørgsel i afviklingen af programmet?

Første gang, man installerer en debugger til at django projekt (og der den sags skyld de fleste andre ORM systemer), så bliver man chokeret! Du oplever det typisk ikke, mens du udvikler og datamængden er begrænset, men når systemet er i drift, brugerskaren stiger og datamængden eksploderer, så kan du sidde med alvorlige hastighedsproblemer, hvis programmøren ikke er opmærksom.

I AG Manifest definerer vi alle forespørgsler via en JSON syntax (du behøver ikke at være skarp i SQL), som sikrer at alle data bliver hentet i ét (og kun ét) SQL kald. Men ikke nok med det, vi formaterer resultatet til JSON før resultatet forlader PostgreSQL, således web serveren kun skal videresende informationen til front-end - dette giver vilde hastighedsforbedringer.

En af filosofierne i AG Manifest er samtidig, at en tabel ikke må "røres" af programmører. Alle oprettelser, opdateringer eller sletninger af data foregår via stored procedures, og alle forespørgsler via præ-definerede views. Denne filosofi betyder at alle standard operationer mod databasen er kompileret ind i database cachen (en stærk PostgreSQL facilitet), så databasen skal bruge langt mindre ressourcer på at udføre hver enkelt proces.

Dokumentation og test

Hvis du er programmør, hvordan har du det så med dokumentation? Vi i IT branchen kender alle svaret: Dokumentation er vigtigt og vi burde gøre det, men vi har jo så travlt, så vi når det sjældent. Det samme er også svaret, når det gælder test af kode.

AG Manifest kravsspecifikationen ligger detaljeret og struktureret i form af manifester, og vi kan automatisk danne word dokumenter, der gennemgår hver enkelt detalje af systemet i læsbar og forståelig form.

Samtidig danner AG Manifest automatisk unit tests for hver enkelt tabel, som gør du kan teste data opret, opdatering, sletning og forespørgsler per automatik - med mindre ting bliver meget komplicerede, skal du ikke skrive test cases selv... AG Manifest gør det for dig!

Det er som regel altid problematisk at definere rapporter og statistikker i et nyt system, man udvikler på. For den vigtigste del af disse dele mangler: Nemlig data. AG Manifest har et modul, hvor du kan danne realistiske test data meget nemt, også tusinder eller millioner af poster - en forholdsvis simpel, men oftest overset del af applikationsudvikling.

Wivvies anbefaler afvikling af disse applikationer via NGINX og Gunicorn, og derfor genererer vi også konfigurationsfilerne til disse afviklingssystemer, og sikrer at oplevelsen med at få ting sat i drift bliver mindre problematisk. Vi kan også lave automatiske docker scripts til dig.