| Who | Notes |
|---|
| Václav Jirovský | - Bavil jsem se s Dominikem Ferim. Základní myšlenka webu: sloužit všem občanům, komunikovat lidsky mimořádná opatření. Aktuální web MZČR je hodně oficiální a zdravotnický.
- Wordpress mi tady nepřijde vhodný.
- V doméně .gov jsou nějaké extra požadavky. (Například: Přihlašování přes Active Directory, vynucené MFA přihlašování.)
- Navrhujeme to udělat jako SPA, která si bude tahat data zvenčí. Je to kompatibilní s K8S, dobře to škáluje.
|
| Radko Jiroušek | - Jak by v tom případě vznikal obsah? Měla by vzniknout redakce, která to bude plnit. Nejen text, ale třeba i inforgrafika.
|
| Tomáš Vavrda | - O jakém typu obsahu se bavíme? Viděl jsem nějaké kartičky, ale teď se bavíme o trochu něčem jiném.
|
| - Tohle se ještě dotahuje (viz dokument). Ty první mockupy nejsou nutně reprezentativní.
- Klíčové je lidské vysvětlení situací, předpokládáme tím pádem bohatší obsah než čistý text.
|
| Radek Hřebeček | - Ta dosavadní ukázaná data mně nepřijdou vhodná pro Wordpress, spíš pro databázi.
|
| Václav Jirovský | - Proto říkáme, že Wordpress nám nepřijde ideální.
|
| - Na webu budou popisy situací, FAQ, případně odkazy na výklady ministerstev.
|
| Václav Jirovský | - Proto na to Wordpress není vhodný. Už kvůli trafficu.
- Na .gov totiž nemůžeme použít CDN 🎉
- (konkrétní návrh routování, nestihl jsem zapsat)
- Klíčové je teď vyřešit generování obsahu.
- Když to bude SPA, jak vyřešit deep linking?
|
| Vladimír Smitka | - Zatím nevíme, kdo to bude dělat. I kdyby to byla SPA, potřebujem pár sehraných vývojářů.
|
| - Proto jsme na začátku navrhovali Wordpress, máme tu na něj lidi.
|
| Vladimír Smitka | - Tady ale bohužel narážíme na složitost toho obsahu, který se ve Wordpressu rychle reprezentuje blbě.
|
| Václav Jirovský | - Pokud není zcela nutné použít Wordpress, můžem oslovit komunitu a poptat, kdo s čím umí.
- Ideálně poptávat rovnou odborníky na SPA?
|
| Radek Hřebeček | - A když to reprezentujeme jako JSON? A editovat například přes Strapi?
|
| Tomáš Vavrda | - Do zítřka můžu dodat frontend pro editaci těch dat i s jejich složitosti, výstupem může být API s JSON a dál s tím můžem dělat, co chceme.
- Jsem smířený s tím, že to třeba bude jen prototyp a klidně použijem něco jiného.
- Máme na to ve firmě systém Origami, ve kterém se dělají takové databázové informační systémy, je to OSS aplikace.
- Jako databázi to může použít třeba PostgreSQL.
- Mělo by to krásný frontend pro lidi, bylo by to rychle k mání.
|
| Radek Hřebeček | - Tohle by bylo ideální rozdělení na BE a FE, propojený přes ten JSON.
|
| Václav Jirovský | - Pokud máme v komunitě nějaké SPAčkaře, třeba už něco takového znají.
- Zkusím rozhodit sítě
- Našel jsem například https://craftercms.org
|
| Vladimír Smitka | - S taxonomiemi umí dobře pracovat třeba i Drupal.
|
| Víclav Jirovský | - Klientů může být i víc, například eRouška.
|
| - Máme už teď představu o schématu toho JSON?
|
| - Navrhovaný obsah je v tomhle už docela reprezentativní.
|
| - Je potřeba pamatovat taky na nějaký úvodní obsah, kvůli SEO.
|
| Stručné shrnutí: - Chceme SPA aplikaci (React?), která načte nějaká strukturovaná data v JSON a zobrazí je.
- Schéma toho JSON teprve bude upřesněné.
- Následně bude potřeba backend/CMS, který nabídne přátelskou editaci těch strukturovaných dat a vystaví je jako JSON.
- Dokud nebude backend/CMS, můžeme ten JSON vyrobit na koleně, ať má frontend podle čeho pracovat.
|
| Former user (Deleted) | Minimální požadavky na docker image a backend/fronted aplikaci: - Image Nakit nasazuje do AKS z vlastního Azure Container registry, neboť nám tam běží skenování na zranitelnosti docker image (používejme jako base image oficiální aktuální image)
- Image musí podporovat non-root běh: Running container as non-root
- Aplikace backendu i frontendu musí sbírat telemetrii a logovat do Azure Application insights. Jsou k dispozici mraky SDKček
- Nakit zajistí CI/CD pipelajny pro automatizovaná nasazení
- Pokud aplikace bude vyžadovat autentifikaci uživatelů, nechť je podporovaná MFA (SMS, Auth aplikace od google, Microsoft, apod.)
|