Návrh architektury OKCZ 3.0
Cílem je rozdělit aplikaci obalkyknih.cz na frontend, který je jen pro čtení (možná kromě nového api pro vkládání) a backend sloužící pro import nových obálek z jednotlivých zdrojů udržující hlavní datový model pro deduplikaci, provázání jednotlivých entit a do budoucna možnost doporučování.
Frontend bude nově implementován pomocí moderních nosql technologií umožňující případný provoz v cloudu a to i bez spojení s backendem (na způsob CDN - Content Delivery Network, ale bez potřeby geografické optimalizace).
Jako backend bude sloužit současné řešení nad aplikačním serverem Catalyst (Perl MVC web application framework) rozšířený o (pravděpodobně dávkové) aktualizace frontendu.
Frontend poskytne vylepšené api pro poskytnutí metadat na základě dotazu na konkrétní záznamy (minimálně pomocí identifikátorů podporovaných současným řešením). Dotaz i odpověď bude inspirován api obalkyknih.cz 2.0 s důrazem na identifikaci kontextu jednotlivých vyhledaných záznamů pro možnost pozdějšího doporučování.
Dále poskytne api včetně logování a kontroly práv na základě referer hlavičky dotazu.
- Spolu s obálkami bude zasílána http hlavička etag pro podporu kešování prohlížečem
- Frontend se bude plnit 'líně' na základě dotazu na metadata, to umožní snadné prototypování, nasazení i výměnu frontendu:
- Zaloguje dotaz, pokud to není jen dotaz prohlížeče na ověření platnosti jeho keše
- Pokud zná odpověď na všechny záznamy, odpoví
- Pokud nezná, zeptá se backendu a uloží si vrácená metadata, stáhne si obálky a případné náhledy na obsahy a odpoví
- Pokud nějaký záznam backend nezná, frontend si to poznačí, aby se backendu neptal pořád dokola ale s nějakým časovým odstupem, protože backend se tento záznam pokusí stáhnout ze svých zdrojů v plánovaném čase (současné řešení obalkyknih.cz)
- Pokud je backend nedostupný, frontend si to poznačí a dotazy na backend nebude provádět dokud neuplyne nějaký delší timeout na backend (nebudou se ukládat do nějaké fronty)
- Dále poskytne api pro zadání komentáře a hodnocení pod přihlašovacími údaji organizace/knihovny, tedy přes jejich server, nikoli prohlížeč (? OpenID ?)
- Poskytne api pro nahrání / nahrazení obálky, tuto zaloguje a pokusí se rovnou nahrát na backend?
Ukládány jsou jednotlivé dokumenty v NoSQL databázi. Jména jejich kolekcí prozatím odpovídají analogickým tabulkám v datovém modelu backendu:
- book – kompozitni denormalizovaný dokument včetně všech identifikátorů, vracených metadat, review, rating, ... (budoucí normalizace jen z případných výkonnostních důvodů)
- fileblob – obálka/náhled toc včetně etag, provázán s dokumentem book
- library – řeší práva podle referer hlavičky
- log – logování
Backend pojede v kopii virtuálního serveru obalky2 na cbvk, současný kód bude potřeba doplnit:
- Periodicky se bude aktualizovat z ostrého serveru obalkyknih.cz (MZK)
- Periodicky bude stahovat nově nahrané / nahrazené obálky z frontendu
- Periodicky bude nahrávat přes api nebo zneplatňovat nahrazené obálky z jiných zdrojů (web obalkyknih.cz)
- Poskytne podporu pro počáteční dávkové (bulk) naplnění frontendu (není nutně potřeba, pouze optimalizace)
- Backend bude výhledově periodicky číst kontext dotazů a logy ukládané frontendem a ukládat je do svých datových struktur pro provázání souvisejících záznamů pro plánované doporučování.
- Aplikační server Node.js
- Databáze MongoDB (kvůli relativně malé velikosti ukládaných obrázků pravděpodobně nebude využit GridFS)
- pravděpodobné použití žurnálu pro bezpečnost zápisových operací
- je potřeba zvážit, který konektor do databáze použít (nativní mongodb, mongojs nebo mongoose)
- Postup vývoje:
- vývoj prototypu lokálně
- výkonnové testy na virtuálním serveru cbvk
- deploy na PaaS řešení RedHat OpenShift v bezplatné verzi pro ověření možnosti běhu v clusteru / cloudu
- Ostrý provoz na virtuálním serveru cbvk
- frontend pojede v samostatném virtuálním serveru vedle virtuálního serveru pro backend (obalky2)
