AMPSU juhtum: Medusa e-pood ja tasulised retseptid

AMPSU on kodukokkadele mõeldud bränd: pitsaahjud, tarvikud, jahud ja retseptid. Poe ja retseptide taga on sama inimene ja sama idee, nii et ka veebis pidid need olema üks tervik. Selles postituses räägime, kuidas me selle platvormi üles ehitasime, miks valisime just need tööriistad ja mida me teel õppisime.

Lühidalt

• Veebileht: üks Next.js-i esileht aadressil ampsu.ee, kus on korraga nii e-pood kui ka retseptid.
• E-pood: Medusa haldab tooteid, laoseisu ja tellimusi. Makseid võtab vastu Montonio, pakid saadab teele Omniva.
• Retseptid: sisu hallatakse Directuses, tellimusi ja makseid Stripe'is.
• Seis: kirjutamise hetkel töötab e-pood ampsu.ee-s. Retseptiplatvorm on koodis valmis ja ootab lõplikku käivitamist.

Lähteülesanne

AMPSU müüb füüsilisi tooteid ja soovib lisaks pakkuda tasulisi retsepte. Need on kaks väga erinevat äri:

• Füüsiline kaup vajab laoseisu, pangalingimakseid, pakiautomaate ja jälgimiskoodi.
• Digitaalne sisu vajab kasutajakontot, korduvmakseid ja kontrolli selle üle, kes mida näha tohib.

Kliendi jaoks peab see aga olema üks koht. Kui retseptis on pitsa, peaks sealt jõudma otse pitsaahjuni. Kui inimene ostab ahju, peaks ta leidma ka retseptid, mida sellega teha.

Miks kaks süsteemi, mitte üks

Esimene küsimus oli, kas panna kõik ühte platvormi. Otsustasime seda mitte teha. Tellimuse täitmise loogika ja sisu tellimise loogika on nii erinevad, et nende ühte süsteemi surumine oleks teinud mõlemad kehvemaks.

Nii ongi AMPSU-l kaks alamsüsteemi, mis jagavad sama esilehte ja domeeni, kuid millel on eraldi maksed, sisu ja kliendiandmed.

E-pood: Medusa, Montonio ja Omniva

Medusa on avatud lähtekoodiga headless e-kaubanduse platvorm. Valisime selle, sest see annab valmis tooted, ostukorvi, tellimused ja haldusliidese, kuid ei sunni peale kindlat kujundust ega kindlaid makse- ja tarnepartnereid. See oli oluline, sest Eestis ootab ostja pangalinki ja pakiautomaati, mitte ainult kaardimakset ja kullerit.

Montonio tegeleb maksetega. Klient maksab Montonio kaudu oma pangas ja Medusa loob tellimuse alles siis, kui Montonio on makse kinnitanud. Makse summa arvutatakse alati serveris ostukorvi põhjal, mitte ei võeta brauserist.

Omniva puhul läksime otseühenduse teed. Alguses registreeriti saadetised Montonio kaudu, hiljem viisime selle Omniva enda liidesele. Nüüd juhtub pärast makset järgmine:

1. Saadetis registreeritakse automaatselt Omnivas ja saab jälgimiskoodi.
2. Medusas märgitakse tellimus täidetuks ja kood lisatakse tellimuse juurde.
3. Klient saab kinnituskirja, milles on Omniva jälgimislink.
4. Iga 15 minuti järel küsib süsteem Omnivast uusi sündmusi ja uuendab tellimuse olekut, näiteks „tarnitud”.
5. Kui Omniva saadetise tagasi lükkab, saab poepidaja e-kirja koos põhjusega ja saab aadressi halduses parandada.

Tarne toimib Eestisse, Lätti, Leetu ja Soome, sest nendes riikides on Omnivaga otseleping. Tasuta tarne piir on pakiautomaati ja kullerile erinev, sest kulleri kulu on suurem.

Retseptid: Directus ja Stripe

Directus on sisuhaldussüsteem, kuhu sisutiim lisab retseptid: koostisosad, sammud, valmistusaja, kategooriad ja märksõnad. Me ei hakanud retsepte Medusasse toodeteks tegema, sest retsept ei ole kaup. Sellel on hoopis teistsugune struktuur ja seda muudetakse palju sagedamini.

Stripe haldab retseptide tellimust. Valisime Stripe'i, sest korduvmaksed, plaani vahetamine, tühistamine ja makseviisi uuendamine on seal valmis kujul olemas. Klient saab oma tellimust ise hallata ja meil ei olnud vaja seda loogikat nullist ehitada.

Tasuline sisu: tellimus või üks retsept

Tasuliste retseptide juures on kaks valikut:

• Tellimus kuu või aasta kaupa, mis avab kõik tasulised retseptid.
• Üksik retsept, mis jääb ostjale alatiseks avatuks. See on mõeldud neile, kes tahavad proovida, enne kui tellimusega seotakse.

Osa retsepte on tasuta. Kasutaja saab konto luua e-posti ja parooliga või Google'i kontoga.

Ligipääsu kontrollime oma rakenduses, mitte Directuse õigustega. Directus näitab avalikult ainult avaldatud sisu. Kas konkreetne inimene tohib retsepti täismahus näha, otsustab rakendus tema tellimuse või ostu põhjal. Stripe teavitab meid iga muudatuse korral: tellimus algas, muutus või lõppes. Rakendus uuendab selle põhjal kasutaja tellimuse oleku, nii et ligipääs vastab alati sellele, mille eest on makstud.

Kus pood ja retseptid kohtuvad

Kuigi taustasüsteemid on eraldi, näeb klient ühte lehte.

• Retseptilt tooteni. Iga retsepti juures pakutakse e-poe tooteid, mis sobivad selle kategooriaga. Pitsaretsepti all on pitsaahjud ja tarvikud, grilliretsepti all tulealused. Tooted tulevad otse Medusast, nii et hind ja pilt on alati ajakohased.
• Filtrid, mis aitavad valida. Retsepte saab sirvida toidu tüübi, valmistusaja, raskusastme ja meeleolu järgi.
• Minu köök. Kasutaja märgib, mis tal kodus olemas on, ja näeb retsepte, kus neid koostisosi kasutatakse.
• Tasuta Õpinurk. Osa retsepte ja nippe on kõigile avatud ning need on ka avalehelt kättesaadavad.

Sisutiimile kirjutasime lühikesed eestikeelsed juhendid: kuidas retsepti märgendada, et filtrid seda leiaksid, ja kuidas täita tootelehte nii, et Medusa kirjeldusest tekiksid automaatselt eraldi sektsioonid, näiteks põhiomadused, komplekt, tehnilised andmed ja KKK.

Mida me teel õppisime

Ükski projekt ei lähe päris plaani järgi. Mõned otsused, mida tasub teada, kui plaanid midagi sarnast:

• Liiga range kontroll võib müüki takistada. Lisasime kassasse postiindeksi kontrolli, et Omniva ei lükkaks saadetist pärast makset tagasi. Selgus, et kontroll lükkas tagasi ka päris Eesti kliente, ja me eemaldasime selle. Selle asemel jäid lihtsamad kaitsed: telefoninumber on kohustuslik ja riikide valik piirdub nende neljaga, kuhu päriselt saata saab.
• Ostukorv peab kiirele klikkijale vastu pidama. Kui klient muutis kogust väga kiiresti, põrkasid ostukorvi muudatused omavahel kokku. Lahendasime selle kahest otsast: brauser saadab muudatused järjekorras ja Medusa lukustamine käib nüüd Redise kaudu.
• Kaks eraldi kontot on teadlik kompromiss. Retseptitellija konto ja e-poe ostja on praegu eri süsteemides. Nii on mõlemad pooled lihtsamad ja üks ei saa teist katki teha. Hind on see, et klient võib vajada kahte sisselogimist.
• Jagatud andmebaas on praegu piisav. E-pood ja retseptid kasutavad sama Postgresi andmebaasi. See hoiab kulud ja halduse väiksena, aga tähendab, et varundus ja katkestused puudutavad mõlemat korraga. Oleme selle üles kirjutanud ja eraldame need, kui selleks tekib päris vajadus.
• Uus osa läheb käiku ilma poodi segamata. Retseptiplatvorm ehitati eraldi harus ja testiti eelvaatekeskkonnas päris e-poe taustsüsteemi vastu. Põhikoodi jõudes jääb see välja lülitatuks, kuni kõik seadistused on paigas, ja e-pood töötab vahepeal edasi nagu varem.

Kellele selline lahendus sobib

Selline ülesehitus on mõttekas, kui müüte nii füüsilist kaupa kui ka digitaalset sisu ja soovite, et klient liiguks nende vahel loomulikult. Samuti siis, kui valmis e-poeplatvormi mallid jäävad kitsaks, kuid kõike nullist ehitada ei taha.

Kui teil on ainult väike tootevalik ilma lisateenusteta, on valmis platvorm tõenäoliselt parem valik. Ütleme selle ka ise ausalt välja.

Räägime

Kas plaanite e-poe arendust, Montonio ja Omniva integratsiooni või tasulist sisu tellimusega? Kirjeldage meile oma olukorda ja arutame koos, mis teie puhul mõistlik on. Võtke meiega ühendust.