Miten verkkokaupan arkkitehtuuri paljastuu – ja miksi se kannattaa rakentaa uusiksi

Tyypillinen toimintajakso:

1. Selain lataa HTML-app-shellin.
2. Selain lataa JS/CSS-tiedostot, jotka on hashettu – nämä voidaan välimuistittaa pitkäksi aikaa, koska tiedostonimi muuttuu buildin yhteydessä.
3. React käynnistyy #root-elementissä ja reititin lukee location.pathname valitakseen oikean komponentin.
4. Sivu lukee bootstrap-datan tai hakee tiedot REST-päätepisteestä, jos data puuttuu tai on vanhentunut.
5. React renderöi DOMin ja kiinnittää tapahtumakäsittelijät.
6. Seuraavat navigoinnit käyttävät History APIa: vain tarvittavat komponentit ja data vaihtuvat.

Tärkeä erottelu: window.__... -muuttujien olemassaolo ei todista palvelinpuolen renderöintiä (SSR). Jos HTML sisältää vain JSONia ja tyhjän rootin, kyseessä on bootstrap/esilataus asiakaspuolen renderöinnille (CSR), ei valmiiksi renderöityä tuotesisältöä. SSR on käytössä vasta, kun tuotteiden nimet, kuvaukset, hinnat ja metatiedot ovat HTML:ssä ennen JavaScriptin suoritusta.

Kiinteän app-shellin käyttö jokaisella reitillä luo nopean SPA-kokemuksen ensimmäisen latauksen jälkeen, mutta alkuperäispalvelimen on käsiteltävä fallback oikein: jos /product/olemassaolematon palauttaa app-shellin statuskoodilla 200, hakurobotti saattaa nähdä sen pehmeänä 404-virheenä. Google suosittelee, että reitit, jotka käyttävät asiakaspuolen renderöintiä, ilmoittavat virhetilanteesta joko noindex-tagilla tai ohjaamalla oikeaan 404-sivuun .

1.3 Katalogidatan virta

Päätepisteet osoittavat, ettei frontend sisällä katalogia suoraan bundleen:

• GET /api/products?limit=500&active=1 hakee myytävät tuotteet.
• GET /api/products?q=... hakutoimintoon.
• GET /api/products/<slug> tuoteyksityiskohtiin.
• GET /api/products/categories taksonomiaan.

Hyvä puoli: frontendin ja katalogin päivitys on eriytetty – tuotetietoja voi muuttaa tietokannassa ilman Vite-buildia. Tämä on selvä etu verrattuna tuotteiden koodaamiseen suoraan Reactissa.

Huono puoli: limit=500 viittaa siihen, että rajapinta on optimoitu pienelle katalogille. 16 tuotteella yksi pyyntö on nopea, mutta tuhansien tuotteiden kanssa payload, kyselyaika, selaimen muisti ja välimuistin tyhjennys kasvavat tarpeettomasti. Uudessa arkkitehtuurissa tulisi käyttää kursori-paginaatiota, kenttäprojektiota ja erillisiä päätepisteitä hakua ja suodatusta varten.

Nykyinen tuoteskeema on tuotekeskeinen eikä varianttikeskeinen. Esimerkkejä:

• stock on tuotetasolla, vaikka variants-kenttä on olemassa.
• sizes, colors, genders sekä tuotetasolla että toistettuna varianteissa.
• Epäjohdonmukaisuudet: XXL vs 2XL, ink navy vs Ink Navy.
• image ja images saattavat osittain päällekkäin.
• type ja isbn viittaavat geneerisiin tai uudelleenkäytettyihin kenttiin.

Tekninen ongelma: todellinen varasto ja SKU kuuluvat varianttiyhdistelmille (esim. Black/M vs Black/L), ei tuotteelle. Epästandardit option tekstit tekevät suodatuksesta, analytiikasta ja kuvien yhdistämisestä epävarmaa. Uudessa arkkitehtuurissa SKU, varasto ja optiot tulisi normalisoida varianttitasolle.

1.4 Kotisivun rakentaja

Asetus section_order ja objektit käynnistys-/sammutuspainikkeineen osoittavat, että kotisivu on CMS:n ohjaama koostumus, ei kovakoodattu komponenttijärjestys.

Mahdollinen renderöintiprosessi:

1. /api/homepage palauttaa konfiguraation eri osioista.
2. Frontend käy läpi section_order-taulukon.
3. Jokainen avain (hero, trustbar, catshowcase, promo, products) yhdistetään React-komponenttiin.
4. Renderöijä tarkistaa onko osio päällä ennen komponentin luomista.
5. Komponentti lukee vastaavan datan (kuvat, tekstit, CTA, tuoteviittaukset, tarjouksen voimassaolo).

Vahvuus: markkinointi voi muokata osioiden järjestystä ja näkyvyyttä ilman frontend-julkaisua.

Heikkous: sekä ann että announcement-avaimet viittaavat päällekkäisiin tai siirtämättömiin tietoihin. Jos section_order, päälle/pois-painikkeet ja payload ovat kolme erillistä rakennetta, ne voivat epäsynkronoitua: avain on järjestyksessä mutta ilman payloadia, tai päälle/pois-tila on eri nimellä.

Uudessa arkkitehtuurissa käytettäisiin yhtä uniikkia listaa lohkoista, joista jokaisella on id, kind, enabled, position, payload ja schema_version. Tämä pitää järjestyksen, tilan ja datan samassa aggregaatissa ja vähentää synkronointivirheitä.

1.5 Layout-rakentaja ja asetukset

/api/layout sisältänee header/footer/navigation-konfiguraation, kun taas /api/public/settings sisältää brändi- ja kauppakäytännöt. Layoutin erottaminen kotisivusta on järkevää, koska header/footer näkyvät kaikilla reiteillä, kun taas kotisivun koostumus koskee vain etusivua.

Asetukset osoittavat avain-arvo- tai JSON-konfiguraatiota, joka ohjaa:

• brändiä ja värejä;
• logoa ja faviconia;
• yritystietoja;
• toimituskuluja ja ilmaisen toimituksen rajaa;
• käsittely- ja toimitusaikoja;
• maksupalveluntarjoajaa ja PayPal-asiakastunnusta;
• some-linkkejä, maksutapoja, navigointia ja ilmoituksia;
• erikoiskampanjaa (ulkovaatteiden ale).

Hyvä puoli: hallinnointi on joustavaa – uuden avaimen lisääminen ei vaadi migraatiota.

Huono puoli: avain-arvo-muotoiltu konfiguraatio on vailla tyyppiturvaa, viiteavaimia ja kenttien välistä validointia. Esimerkiksi standard_handling_min ei saa olla suurempi kuin standard_handling_max; paypal_sandbox tulee olla totuusarvo; some-URLit tarvitsevat validointia. Uudessa arkkitehtuurissa tulisi käyttää skeemavalidointia ja erottaa julkinen konfiguraatio salaisesta.

Tietoja kuten tax_id, juridinen osoite, operatiivinen sähköposti tai muut ei-julkiset tiedot ei tulisi palauttaa julkisista asetuksista. PayPal-asiakastunnus voi olla julkinen, mutta asiakassalaisuus (client secret) kuuluu yksinomaan palvelimelle.

1.6 Kuponkien käsittely ja PayPal-maksut

Mahdollinen maksun kulku:

1. Asiakas lähettää ostoskorin ja kuponkikoodin palvelimelle.
2. Palvelin hakee tämänhetkiset tuote-/varianttitiedot tietokannasta, tarkistaa aktiivisuuden, varaston ja tarjoukset.
3. Palvelin laskee itse välisumman, alennuksen, toimituskulut, verot ja loppusumman.
4. POST /api/paypal/create-order luo PayPal-tilauksen palvelimen tunnuksilla ja tallentaa yhteyden sisäiseen ostoskoriin.
5. Asiakas hyväksyy maksun PayPalissa.
6. POST /api/paypal/capture noutaa hyväksytyn tilauksen.
7. Palvelin varmistaa summan, valuutan ja tilan, luo virallisen tilauksen, tallentaa maksuyrityksen ja vähentää/varastoi varaston.
8. PayPal-verkkokuuntelija (webhook) tarkistaa epäsynkroniset tilat tai katkenneet pyynnöt.

Kriittistä: Palvelin ei saa luottaa price, discount, shipping tai total -kenttiin, jotka selain lähettää – ne tulee laskea palvelimella tuotetietojen ja sääntöjen perusteella.

Kaksi päätepistettä (create/capture) on oikea suunta, mutta laatu riippuu:

• Idempotenssiavaimeista (estääkseen kaksoisluonnin tai -nappauksen).
• Transaktioista/lukituksista (estääkseen ylimyynnin).
• Maksuyrityksen tallennuksesta ennen palveluntarjoajan kutsumista.
• Verkkokuuntelijan allekirjoituksen varmistuksesta.
• Valuutan ja summan tarkistuksesta.
• Selkeästä tilakoneesta.
• Täsmäytystyöstä (jos PayPal hyväksyy, mutta vastaus katoaa).

1.7 Arvostelut, uutiskirje, yhteydenotto ja tilauksen seuranta

Nämä päätepisteet tekevät backendista todellisen verkkokauppasovelluksen, eivät pelkän katalogi-API:n.

• Arvostelut: vaaditaan tila (odottaa/hyväksytty/hylätty), roskapostinesto, nopeusrajoitukset ja ostajan varmistus. POST /api/reviews/<id> on outo nimi luomistoiminnolle – uudessa arkkitehtuurissa selkeämpi resurssisemantiikka.
• Uutiskirje: vaatii sähköpostin normalisoinnin, uniikkisyysrajoitteen, kaksinkertaisen suostumuksen (double opt-in) lainsäädännön mukaan, peruutuslinkin ja ettei sähköposteja tallenneta selkeänä tekstinä.
• Yhteydenotto: vaatii CAPTCHA- tai bot-eston, nopeusrajoituksen, sähköpostijonon – HTTP-pyyntö ei saa olla suoraan riippuvainen sähköpostipalvelimesta.
• Tilauksen seuranta: ei saa sallia lyhyitä numeroita. Suositeltavinta on signed-token tai tilausviite + sähköposti/postinumero -yhdistelmä + nopeusrajoitus. Julkinen päätepiste voi altistaa PII-tietoja ja ostohistoriaa.

1.8 Analytiikka/seuranta

POST /api/track kerää todennäköisesti sivu-, kampanja- tai verkkokauppatapahtumia omaan backendin. Etuna on vähentää riippuvuutta asiakaspuolen analytiikasta ja toimia paremmin mainosesto-ohjelmien kanssa. Haittana on, että se vaatii suostumuksen, säilytyskäytännön, tapahtumaskeeman ja botineston.

Tapahtumapäätepiste ei saa tallentaa mielivaltaista JSONia loputtomiin. Tapahtumien nimien ja ominaisuuksien tulee olla whitelistattuja, koko rajoitettu, PIT-tiedot poistettava tai hashattava ja pyynnöt ohjattava jonon kautta.

1.9 Mahdollinen backend-teknologia

Node.js (Express/Fastify/NestJS): Looginen valinta, koska React/Vite-frontend on usein samassa TypeScript-ekosysteemissä. JSON-serialisointi ja middleware-toiminnot ovat luontevia, ja palvelimen window.__INITIAL_DATA__:n lisääminen on helppoa. Tämä on kuitenkin vain ekosysteemipäätelmä, ei todiste.

PHP (Laravel/Symfony): Mahdollista; Laravel tarjoaa helposti REST-ohjaimet, tietokantamigraatiot, jonot, sähköpostit, validoinnin ja voi palauttaa Vite-app-shellin catch-all-reitiltä. Cloudflare voi peittää kaikki X-Powered-By- tai evästemerkit.

Python (FastAPI/Flask/Django): Mahdollista; FastAPI/Flask tekee helppoa JSON REST-APIa, ja Vite-build voidaan tarjoilla Nginxistä tai staattisesta alkuperästä.

Johtopäätös: Todisteet eivät riitä back-end-kielen varmistamiseen. Luvallisia tapoja saada tietoa (omassa järjestelmässä) ovat deployment-tiedostot, prosessinhallinta, lukitiedosto, container-kuva, vastausotsikot (ilman Cloudflarea), evästeet, OpenAPI, virhekuori ja tietokanta-ajuri. Pelkistä URL-nimeämiskäytännöistä ei pidä vetää johtopäätöksiä.

1.10 Tekniset vahvuudet

• Alustariippumaton UI: React ei ole sidottu PHP-teemaan tai WooCommerce-sivuihin; koko näkymäkerros on omassa komponenttipuussa.
• Staattisten resurssien hyvä välimuistitus: Vite-hashing mahdollistaa Cache-Control: immutable; uusi deployment tuottaa uudet tiedostonimet.
• Riittävä CMS brändille: kotisivu/layout-rakentaja keskittyy tarkasti tarvittaviin lohkoihin.
• Selkeä API-alue: katalogi, sisältö ja operaatiot voivat palvella eri kanavia (web, app, admin).
• Vähän lisäosia: vähentää teema-/lisäosariippuvuuksia ja niiden ristiriitoja.
• Nopea navigointi ensimmäisen latauksen jälkeen: dataa ja komponentteja vaihdetaan.

1.11 Heikkoudet ja riskit

• Ensimmäinen lataus riippuu JavaScriptistä: app-shell ei sisällä tuotesisältöä, joten lataus, jäsennys, suoritus ja API-pyyntö viivästyttävät sisältöä.
• API-vesiputous: useat peräkkäiset kutsut (asetukset, kotisivu, layout, tuotteet) pidentävät LCP-aikaa.
• SEO/statuskoodi: catch-all-app-shell tuottaa helposti jaetun otsikon ja pehmeän 404-virheen; sosiaalisen median hakurobotit eivät välttämättä suorita JavaScriptiä.
• Välimuistin tyhjennys monimutkaista: katalogilla, kotisivulla, layoutilla ja asetuksilla on eri TTL-arvot.
• Oma liiketoimintalogiikka: kuponkien, tilausten, verojen, hyvitysten, varaston, verkkokuuntelijoiden ja hallintapaneelin koodi vaatii itse testaamista – ei valmista ekosysteemiä.
• Datamalli on standardoimaton: väri-/kokotaulukot ja varasto tuotetasolla vaikeuttavat laajentamista SKU-varastoon.
• Turvallisuus: kontaktin, arvostelun, uutiskirjeen, seurannan ja maksun julkiset päätepisteet vaativat validointia, nopeusrajoitusta ja idempotenssia.
• Yksittäisosaajariski: jos vain yksi henkilö ymmärtää kustomoidun backendin ja rakentajan, luovutuskustannukset ovat suuret.

2. Suora vertailu WooCommerceen

2.1 Onko kustomoitu SPA