Hozzájárulási architektúra, amely projekteken átívelően működik

A webalkalmazások gyakran építenek be külső szolgáltatásokat: analitikát, térképet, videót vagy időpontfoglalást. Ezzel további adatáramlások keletkeznek, és felmerül a kérdés, milyen feltételek mellett tölthetők be ezek a szolgáltatások.

Sok hozzájárulási megoldást utólag, önálló rendszerként illesztenek egy weboldalhoz. Ezzel további függőségek keletkeznek: a konfiguráció és a felület az alkalmazáson kívülre kerül, külső szkriptek épülnek be a technikai betöltési útvonalba, az egyes integrációk feletti kontroll pedig több rendszer között oszlik meg.

A saját projektjeinkben ezért a hozzájárulást közvetlenül az alkalmazás architektúrájába akartuk illeszteni.

Ebből jött létre az önálló hozzájárulás-motor, amelyet ma közös technikai modulként használunk.

A hozzájárulási rendszer tudatosan elválasztja a központi működési logikát a projektspecifikus adatoktól és a látható felülettől.

Így ugyanaz a technikai alap eltérő felépítésű alkalmazásokban is használható anélkül, hogy a hozzájárulási állapotot, a verziózást vagy a szkriptszűrést minden projektben újra kellene implementálni.

Központi elvárás volt, hogy a hozzájáruláshoz kötött szolgáltatások a hozzájárulás előtt ne csupán kikapcsolt állapotban legyenek. Egyáltalán ne töltődjenek be.

Ehhez több mechanizmus kapcsolódik össze.

Annak érdekében, hogy a bejelentett tárolási értékek és a tényleges implementáció ne egymástól függetlenül alakuljon, a motor központi nyilvántartást használ. A hozzájárulási infrastruktúrán keresztül kezelt minden tárolási értékhez technikai tulajdonságokat rögzítünk.

A nyelvfüggő adatokat – például a célt és a leírást – ettől elkülönítve tartjuk karban.

Ha az alkalmazáskód a hozzájárulási infrastruktúrán keresztül nem regisztrált értéket próbál írni, a művelet elutasításra kerül. A nyilvántartás így nemcsak dokumentáció, hanem a technikai kontroll része is.

Minden hozzájárulási konfigurációnak van verziója.

Egy újabb látogatáskor a motor összeveti a tárolt verziót az éppen használt állapottal. Ha a konfiguráció ennek megfelelően megváltozott, a meglévő választás elvethető, és új döntés kérhető.

Egy újonnan hozzáadott szolgáltatás így új hozzájárulási verzióval kezelhető anélkül, hogy minden weboldalhoz külön migrációs logikát kellene fejleszteni.

A hozzájárulás a beállításokon keresztül bármikor módosítható. Ha egy korábban elfogadott kategóriát visszavonnak, nemcsak a tárolt hozzájárulási állapot változik meg.

Az újraépítés azért lényeges, mert a már lefutott harmadik féltől származó szkriptek nem vonhatók vissza megbízhatóan pusztán a szkriptelem eltávolításával.

A visszavonás után az állapotnak ezért olyannak kell lennie, mint egy olyan látogató esetében, aki az adott kategóriát soha nem engedélyezte.

A hozzájárulás-motor és a konfiguráció között meghatározott interfész áll. A motornak bizonyos információkra szüksége van, de nincs ahhoz kötve, hol tárolják ezeket.

Így különböző modellek lehetségesek.

A cookie-nevek, azonosítók, kategóriabesorolások és tárolási idők nyelvsemlegesek. Minden, amit a látogatók olvasnak, ezzel szemben nyelvenként gondozható.

Egy tárolási értéket így technikailag egyszer definiálunk, majd minden szükséges nyelven leírunk.

A Woop Art referenciaprojektben a német és az angol nyelv teljes körűen gondozott. A Woop Technology weboldala ugyanezt a motort használja további nyelvekkel.

A motor újrafelhasználható alapértelmezett felületet biztosít, de nem írja elő a használatát.

A hozzájárulási logika eközben változatlan marad.

A megjelenítés így az adott projekt designrendszeréhez igazítható anélkül, hogy olyan központi funkciókat kellene újraírni, mint a verziózás, a nyilvántartás vagy a visszavonás.

A böngészőben tárolt hozzájárulási állapot mellett minden kifejezetten elmentett döntés szerveroldalon is naplózható.

Az IPv4-címeket a második blokk után, az IPv6-címeket a harmadik szegmens után rövidítjük.

Az erre szolgáló végpont csak azonos eredetű kéréseket fogad el, és rögzített útvonalon található, hogy infrastruktúra szinten is célzottan korlátozható legyen.

A látogató döntése először az alkalmazás hozzájárulási állapotában lép érvénybe. Ha a kiegészítő szerveroldali mentés meghiúsul, a weboldal továbbra is használható marad.

A hiba szerveroldalon kerül naplózásra ahelyett, hogy technikai részletek jelennének meg a böngészőben. A hozzájárulási rendszer működőképessége így nem függ attól, hogy a kiegészítő naplózás minden pillanatban elérhető-e.

A hozzájárulási konfiguráció és a központi motor a saját alkalmazás része. Magához a hozzájárulási rendszerhez ezért nincs szükség külső CMP-szolgáltatóra.

A hozzájáruláshoz kötött szolgáltatások ettől elkülönülnek, és csak akkor töltődnek be, ha a szükséges hozzájárulás rendelkezésre áll.

A hozzájárulás-motor önálló csomagként létezik, és a Woop Technology privát csomagkezelésén keresztül érhető el. A verziók és a változások így ugyanolyan nyomon követhetően kezelhetők, mint bármely más technikai függőség.

Egy új projekt lényegében négy projektspecifikus területet egészít ki.

Saját hozzájárulási architektúra nem minden projekthez szükséges. Kevés külső szolgáltatást használó egyszerű weboldalnál egy bevált hozzájárulási platform lehet a gyorsabb és gazdaságosabb megoldás.

Ezekben az esetekben a közös motor csökkenti a projektspecifikus implementációkat, és lehetővé teszi, hogy a központi funkciókat egy helyen fejlesszük tovább.

A központi hozzájárulási állapot az alkalmazáskód számára is elérhető.

Ezáltal kétkattintásos megoldások is megvalósíthatók. A még nem engedélyezett harmadik fél helyett először egy helyi komponens jelenhet meg, amely tájékoztat a külső szolgáltatásról, és azt csak a megfelelő döntés után tölti be.

A hozzájárulás így nem korlátozódik a sávra és a beállítási ablakra, hanem közvetlenül beépíthető az alkalmazás folyamatába.

Egy külső hozzájárulási platform további szolgáltatót, saját szkripteket, saját konfigurációt és rendszerint egy újabb technikai függőséget hoz magával. A saját motor ezzel szemben a meglévő alkalmazásokkal együtt, a tervezett infrastruktúrán belül üzemel.

Ez nem jelenti azt, hogy a külső hozzájárulási platformok alapvetően alkalmatlanok lennének. A döntés az adott projekt terjedelmétől és követelményeitől függ.

Magához a hozzájárulások kezeléséhez nincs szükség további CMP-szolgáltatóra. A vonatkozó hozzájárulási adatok így ott dolgozhatók fel, ahol az alkalmazás is üzemel.

Azt, hogy egy konkrét projekt milyen további külső szolgáltatásokat használ, és eközben milyen adatok kerülnek továbbításra, ettől függetlenül, projektenként határozzuk meg és dokumentáljuk.

A hozzájárulás-motort ma különböző webalkalmazások újrafelhasználható részeként használjuk. A központi funkciókat egyszer gondozzuk, miközben az adatok, az integrációk, a nyelvek és a felület projektspecifikusak maradnak.