Sådan bygger du skalerbare webapplikation

Du bliver ikke specialist af at læse denne artikel, men den almindelige gennemsnitslige webudvikler til at bygge “mindre håbløse” applikationer 🙂

Det der oftest sker er at en person får en ide til et spændende koncept, hyrer en handelsskoleelev, eller en middelmådig programmør – intet galt i det, jeg kender alt til at man som nyslået iværksætter ikke har råd til lukusmodellen fra dag 1. – problemet er bare, at for det meste ender den oprindelige model med at leve meget længere end først antaget, og virksomheden bliver længere henne i processen ofte tynget af dårlige beslutninger taget af den oprindelige udvikler … beslutninger som i sig selv kan virke ubetydelig, men om 3-4 år er vokset i en grad så det ikke er til at lave om.

Dette har affødt denne artikel, det er en række anbefalinger der er nemme at følge og som enhver der bare er marginalt kvalificeret til at udvikle en hjemmeside, bør kunne forstå og følge.

  1. Forbered siden på at køre fra et CDN, gem alle statiske filer, billeder, javascripts, css filer mv. på et seperat sub-domæne, det kunne f.eks. hedde filer.domæne.dk
  2. GemSESSIONS i databasen, når siden en gang får behov for at køre fra flere webservere vil det være nødvendigt at have centrale session-data, og databasen skal alligevel være delt så det vil typisk være det foretrukne valg.
  3. Lav så meget som muligt i Webbrowseren. Istedet for at reloade hele siden hvergang brugeren laver en lille ændring, så kør en javascript/JQuery funktion der sender en forespørgsel til webserveren og modtager f.eks. et json encoded svar, dette kan f.eks. indeholde nye chat-beskeder eller en reaktion på en bruger handling.Det er meget nemmere for serveren at betjene et enkelt json-kald end at reloade hele siden. Hvis dette gøres gennemført nok kan du faktisk lave hele siden så du loader al html og javascript én gang, og efterfølgende foregå al kommunikation med webserveren via json kald.
  4. Lav én PHP Klasse som står for al kommunikation med database. 
  5. Lav sådan at der kan laves read-write split på dine database queries.En måde at udvide en database applikation til to eller flere fysiske maskiner er at lave et såkaldt master-slave cluster, hvor én fysisk maskine tager sig af alle skrive opgaver mens en eller flere slaver håndterer læsninger.Det betyder principielt at alle ALTER, INSERT, CREATE, DELETE queries skal gå til f.eks. masterdb.domæne.dk mens alle SELECT skal gå til slave1.domæne.dk ELLER slave2.domæne.dk ELLER slave3.domæne.dk
  6. Brug kun InnoDB. Der er meget få gode undskyldninger for at bruge andet, det er ikke noget du bør bekymre dig om, bare vælg InnoDB som standard, i 95% af tilfældende er det dit bedste valg. Hvis du tror du er kommet ud for en af de sidste 5% bør du konsultere en database specialist.
  7. Design dine databaser med omhu. Du skal vide hvad et index er og hvordan man bruger dem, du skal bruge fornuftige typer – dvs. hvis et felt skal indeholde et tal, så må det ikke være en varchar. Alle tabeller skal have mindst én unik nøgle, hvis ikke tabellen har en naturlig nøgle så opfind en (jeg ved godt det strider imod normalformerne – beklager meget, skolen er slut, velkommen til virkeligheden) og når vi nu er ved normalformerne, så brug dem som reference.Undgå “tlf1″,”tlf2″,”tlf3” og undgå “tlf1,tlf2,tlf3” har du behov for mere end et telefonnummer er det yderst sansynligt at der findes scenarier hvor du har behov for ‘n telefonnumre. Lav derfor en seperat tabel til formålet.
  8. Ryd op i dine data, smid gamle data ud.Du bør kun gemme data du har behov for at gemme, der er ikke noget der hedder “vi gemmer det for en sikkerhedsskyld”. Hvis du gerne vil lave statistik, så beregn statistiken og smid de enkelte kliks ud bagefter.Lav en rutine der ved årsskiftet til 2020 trækker data for 2019 ud og gemmer dem i en seperat fil, og sletter dem i databasen.
  9. Hvis ting kan deles op, så del dem op for pokker. Hvis du laver en saas-applikation (eller som det hedder nu til dags, “cloud”) så vær opmærksom på at det ikke nødvendigvis er smart at rode alle dine kunders data sammen i én stor database. Måske kan man lave så alle kunder i f.eks. Danmark har deres egen database? Eller endnu bedre, sådan at hver enkelt kunde har sin egen database?
  10. Dan dig overblik, brug kode versionering og dokumenter din kode.Jeg ved godt der kom et par fy-ord der, men det er for det første noget du selv kan få gavn af, for det andet kan det være knald-eller-fald for virksomheden hvis du en dag ikke er der mere til at rede deres røv når lortet det går ned.Følg med i hvad systemet bruger af trafik, diskplads, cpu, ram osv. Hav styr på hvilke bibliokteker og pakker din kode gør brug af, strø kommentarer ud over koden alle steder hvor det giver mening.
  11. Lav et one-step-deploy script.
    Du skal med én kommando kunne rulle en given version af siden ud på en ny dev- eller produktionsserver. Det giver jeg hurtigere disaster recovery og det gør det nemmere at teste ny kode. Derudover kræver det at du har overblik over din applikation, det vil komme dig til glæde den dag du skal have de første eksterne folk ind over projektet.
  12. Lav pæn kode, jeg mener det, og ikke bare det du “syntes er pænt”.
    Dine variabler, klasser og metoder skal have sigende navne, det skal holdes i et bestemt sprog, typisk engelsk, men dansk kan også godt gå, bare det er konsistent hele vejen igennem. Ikke noget med at bruge bandeord, personer fra star-wars eller planeter, det er nemt at regne: DeployCustomerAppliance(); ud, men det er pænt umuligt at gætte hvad: Jupitor(); gør.
  13. Undgå så vidt som muligt at ændre i fil-træet,og hvis du gør det så sørg for at lave en abstraktionsklasse til det sådan at det i fremtiden nemt kan ændres til f.eks. at uploade evt. filændringer til et CDN eller til flere webservere.Mén billeder, video o.l. bør altid uploades til et CDN, eller ihvertfald en eller anden mekanisme til at håndtere den slags data, og alle andre dynamiske data bør ligge i databasen.
  14. Hold orden i dine filer. Jeg har engang haft en kunde der havde et webdir på 75GB, da vi var færdig med at ryde op og smide gamle database dumps og backup-tarballs ud fylde det pludselig kun 15GB.
  15. Lav fejltollerante applikationer. Tag stilling til hvad der skal se hvis din applikation ikke kan få fat i databasen, eller CDN’et. Hvad er nødløsningen? Skal data caches? Hvor? skal der sendes fejlbeskeder ud? Til hvem? Via hvilket medie? Hvad skal fejlbeskederne sige?
  16. Adskil webdesign og kode, defacto standarden for at gøre det i PHP hedder Smarty, der er simpelthen ingen unskyldning her … inline-kode medfører dødsstraf 😉

Bookmark denne artikel, jeg kommer nok til at udvide den løbende 🙂