Web Development Project: led-lumina.pl

#Bildene er tyngden i en slik katalog

En lampe selges på fotografiet. Fotografier av lamper er krevende å ta og dyre å overføre, for de kommer som regel i flere vinkler, ofte mot mørk bakgrunn, iblant i en romsituasjon. En katalog med flere hundre varer er derfor et bildearkiv med et nettsted festet til, og markupen er en avrundingsfeil ved siden av det.

Det er verdt å si dette først, fordi ytelsesarbeid i slike prosjekter ofte begynner med å minifisere skript. Her lå massen et helt annet sted. Filene behandles ved opplasting til nøyaktig de størrelsene som faktisk brukes: miniatyrbilde i listen, mellomstor visning på produktkortet, full oppløsning i forstørrelsen. Miniatyrbildet er aldri zoomfilen skalert ned i nettleseren, for en skalering i nettleseren sparer piksler og ikke byte, og det er byte den besøkende venter på.

Distribusjonen går over et CDN-lag. Bilder endrer seg ikke etter opplasting, så de kan ligge svært lenge i kantnodene, og et andre besøk på en oversiktsside treffer ikke opprinnelsesserveren i det hele tatt. AWS-siden bærer det som ikke kan leveres fra kanten: lagring av originalfilene, sikkerhetskopier og de kostbare, men engangs, behandlingsstegene.

#Hva en belysningskatalog egentlig er

Tar man vekk fotografiene, står man igjen med en tabell av tall. Lysstrøm, fargetemperatur, fargegjengivelsesindeks, spredningsvinkel, kapslingsgrad, energiklasse, om armaturen kan dimmes og om driver følger med. To produkter i denne katalogen skiller seg fra hverandre på disse tallene og på nokså lite ellers.

For det norske markedet har dette en ekstra dimensjon. En stor del av året er mørk, innendørsbelysning brukes mange timer i døgnet, og valget mellom varmhvitt og nøytralhvitt lys er derfor ikke en detalj, men noe folk merker hver kveld i flere måneder. På den profesjonelle siden styres installasjonen av NEK 400, som setter rammene for hvordan anlegget skal utføres, og en innkjøper leser da kapslingsgrad og sikkerhetsdata før vedkommende ser på hvordan armaturen ser ut.

Konsekvensen for innholdsmodellen måtte avgjøres i uke én. Produktbeskrivelsen kan ikke være et tekstfelt der noen skriver spesifikasjonen som prosa. Den må være et sett av separate egenskaper, for bare da kan man filtrere på dem, sammenligne på tvers og bygge lister over utbyttbare alternativer. Prosa lar seg ikke sortere. Ligger tallene inne i setninger, er eneste måte å svare på et spørsmål om alle armaturer over en viss lysstrøm å lese samtlige setninger.

Numeriske egenskaper lagres derfor som tall og kan avgrenses med intervall. Egenskaper med faste verdier, som lysfarge eller kapslingsgrad, er taksonomier, slik at én merkelapp henger på mange produkter og kan rettes ett sted senere. Skillet ser ut som en administrativ detalj og avgjør om et filter på effektområde er en databasespørring eller et tekstsøk.

#Varianter, og fellen med nesten like sider

Den samme armaturen finnes i flere lysfarger og flere effekttrinn. For kunden er det varianter av én ting. For lageret er det egne linjer med egne beholdninger. Begge synene er riktige, og innholdsmodellen må tjene begge uten å velge side.

Gir man hver variant sitt eget innlegg, formerer produktsiden seg til et dusin nesten identiske dokumenter med de samme fotografiene og nesten den samme teksten. En søkemotor som ser et dusin nesten like dokumenter, velger ett, og valget er ikke ditt. Finnes varianter ikke i det hele tatt, kan man ikke vise beholdning. Løsningen her ble én overordnet oppføring med beskrivelse og galleri, og underordnede varianter som bare bærer parametere og lagerstatus.

#Cache og lagerbeholdning trekker i hver sin retning

Her ligger den vanskeligste avveiningen i hele leveransen, og den gjelder to krav som utelukker hverandre.

En side er rask når den kommer ferdig ut av et mellomlager, uten å vekke PHP og uten å spørre databasen. En side er korrekt når tilgjengeligheten ved siden av produktet stemmer akkurat nå, og tilgjengeligheten endrer seg utenfor nettstedet. Holder cachen dokumentet en time, lover den i en time varer som kanskje ikke finnes lenger. Holder den det ikke i det hele tatt, betaler hvert eneste besøk for full oppbygging av siden.

Løsningen var å slutte å behandle produktsiden som ett objekt. Beskrivelse, bilder, tekniske data og støttetekst er stabile i uker og kan mellomlagres aggressivt. Lagerstatus og tilgjengelighet hentes separat, etter at siden allerede er synlig, og bare de avgjør om bestillingsknappen er aktiv. Dokumentet nettleseren får, er dermed likt for alle, og det eneste tidskritiske elementet på det er tydelig avgrenset.

#Når systemet på den andre siden slutter å svare

Beholdning og sortimentsendringer kommer over et grensesnitt fra et eksternt system. På en arkitekturtegning er det en pil. I drift er det den delen man ikke kontrollerer oppførselen til, og nettopp derfor ligger det et eget lag mellom nettstedet og kilden.

Redis gjør her mindre nytte som fartsøkning på enkeltspørringer enn som noe som lar nettstedet overleve en annens nedetid. Når kilden ikke svarer, leverer mellomlaget det sist kjente svaret i stedet for en tom flate eller en feilmelding. Den besøkende ser en side som kanskje henger litt etter, ikke en side som ser ødelagt ut, og forskjellen mellom de to er forskjellen mellom en utsatt og en tapt ordre.

Oppdateringsintervallene settes etter hvor fort en opplysning faktisk blir gammel, ikke med én verdi for alt. Katalogstruktur og tekniske parametere endrer seg sjelden og kan komme i en samlekjøring. Beholdningen endrer seg i løpet av timer og går i en egen, lett kanal som bare rører lagerfeltet. Den oppdelingen er billigere enn å gjøre én stor import raskere, fordi den ikke korter ned kjøretiden, men omfanget av det som i det hele tatt må regnes ut.

Én regel til melder seg først etter måneder i drift: en full import må aldri overskrive arbeid gjort på nettstedssiden. Salgstekster, miljøbilder, koblinger til beslektede produkter og søkeorientert tekst kommer ikke fra et lagersystem. Hvis importen ikke uttrykkelig lar dem være, spiser den dem før eller siden.

#Filtrering som ikke mister adressen

Grensesnittet henter resultater asynkront, slik at et filterbytte ikke laster hele siden på nytt. Det er en udramatisk forbedring, og den bærer en felle som mange kataloger fra denne perioden gikk i.

Har en filtrert resultatliste ingen egen adresse, kan den ikke bokmerkes, ikke sendes videre og ikke indekseres. Det dynamiske laget arbeider da direkte mot den synligheten resten av prosjektet prøver å bygge. Filtertilstanden speiles derfor i adressen selv om ingen sideinnlasting skjer, og den som åpner adressen kaldt, får samme liste som den som klikket seg dit.

Betjeningen hører til samme punkt. Filtre må kunne brukes med tastatur, og en tabell med tekniske data trenger overskriftsceller som er knyttet til datacellene. Uten den koblingen leser en skjermleser spesifikasjonen som en rekke tall uten merkelapp, og spesifikasjonen er innholdet på denne siden, ikke pynt rundt det.

#Synlighet når alle har samme tekst

Et redaksjonelt nettsted skriver tekstene sine selv. En handelsside arver dem. Produsentbeskrivelser går til hver forhandler, så de samme setningene står på et dusin konkurrerende sider, og en søkemotor velger ett dokument blant et dusin nesten like. Den minste aktøren i den gruppen vinner sjelden.

Svaret ligger i laget ingen produsent leverer. Kategori- og filtervisninger får egne innledende tekster, skrevet mot spørsmålet en kjøper faktisk stiller: hva forskjellen mellom varmhvitt og nøytralhvitt betyr i et rom man sitter i om kvelden, når kapslingsgraden virkelig har noe å si, hva det betyr at en spesifikasjon tier om dimming. Ingenting av dette finnes i en produsentfil, fordi en produsent beskriver et produkt og en kjøper tar en avgjørelse.

Strukturerte data beskriver produktet i en form en søkemotor kan lese, og semantisk HTML5 ordner dokumentet slik at de tekniske dataene er en tabell og ikke rader plassert for å ligne på en. Det andre poenget er tilgjengelighetspoenget fra forrige avsnitt, bare sett fra en annen kant, og når et argument dukker opp to ganger uavhengig, var avgjørelsen som regel riktig.

#Betaling, frakt og grensen for eget ansvar

Betalingsformidlere og fraktsystemer tar med seg en feilklasse som ikke finnes noe annet sted i prosjektet. Enhver annen feil kan rettes og handlingen gjentas. En betaling skjer én gang, resultatet kommer utenfra, ofte forsinket og av og til to ganger.

Bekreftelsen av en ordre kan derfor ikke hvile på at noen kommer frem til takkesiden. De kommer frem eller ikke: fanen lukkes, dekningen ryker, noen trykker tilbake. Ordrestatus avgjøres bare av varselet som kommer inn fra operatøren, og håndteringen av det varselet må tåle å bli kalt flere ganger, for en operatør i tvil sender på nytt. Tåler den det ikke, blir én betaling til to ordrer.

For frakt går grensen på samme måte. Nettstedet kjenner vekt og mål på det som ligger i kurven og kan regne ut en kostnad. Det kjenner verken transportørens kapasitet akkurat nå eller kortsiktige begrensninger, og later ikke som. Å si den grensen høyt er mer nyttig enn et anslag som av og til er selvsikkert feil.

#Sikring der den er billig

Sikringen ligger i koden og på serveren, ikke i en utvidelse som lover beskyttelse. Begrunnelsen er teknisk: en sikkerhetsutvidelse kjører i samme PHP-prosess som resten av nettstedet og kan først reagere når forespørselen allerede har nådd den prosessen. Ratebegrensning og filtrering i kantlaget stopper den samme forespørselen tidligere og billigere.

Inne i applikasjonen teller det som skjer med inndata. Skjemaer valideres på serveren, for validering i nettleseren er brukervennlighet og ikke en kontroll. Handlinger som endrer tilstand er beskyttet mot å utløses fra en fremmed side. Databasespørringer er parametriserte, slik at tekst noen har skrevet aldri blir en del av spørringssyntaksen.

#Drift etter lansering

Den løpende driften omfattet oppdatering av kjerne, tema og utvidelser, gjennomgang av logger og regelmessige sikkerhetskopier. Listen høres rutinepreget ut, så det er verdt å si hva som skiller den i en butikk fra den samme listen på et visittkortnettsted.

En oppdatering i en katalog koblet til et eksternt system er ikke en operasjon med ett klikk. En endring i kjernen kan berøre hvordan grensesnittet oppfører seg, og det viser seg først ved neste synkronisering. Endringer gikk derfor gjennom et testmiljø med en kopi av ekte data, ikke gjennom en ren installasjon med demotema. En katalog med flere hundre varer og flere integrasjoner oppfører seg ikke i nærheten av et tomt WordPress, og randtilfeller dukker bare opp mot en realistisk datafordeling.

Sikkerhetskopier har her en annen oppgave som nevnes sjeldnere. Det verdifulle i en butikk er ikke filene, men databasen med ordrene, så gjenoppretting må øves og ikke bare påstås. En sikkerhetskopi ingen noen gang har lest tilbake, er en antakelse.

#Hva som følger med videre

Arbeidsmåten følger med: skille stabile data fra data som endrer seg fort, føre egenskaper som felter og taksonomier i stedet for prosa, legge et mellomlag foran ethvert eksternt system, og teste mot en kopi av produksjonen. De avgjørelsene ser like ut i enhver katalog, uavhengig av bransje.

Innholdsmodellen og integrasjonene følger ikke med. De ble bygget rundt én kundes data og ett oppdrag i kategorien Strony www. Et egenskapssett for belysning betyr ingenting utenfor belysning, og formen på en datautveksling avhenger av hva som står på den andre siden. Neste leveranse begynner med en gjennomgang av omfanget, og tilbudet kommer etter den og ikke før.