Multijazyčný web s oddělenými databázemi
- dreken
- Člen | 36
Mám web, který běží v různých mutacích, přičemž databáze jsou oddělené, protože data v různých lokalitách jsou jiná. Kód projektu je ale samozřejmě pro všechny mutace naprosto stejný. Všechny statické texty jsou oddělené v jazykových souborech.
Proto bych chtěl, aby byl projekt na serveru uložený pouze jednou a pak se postupovalo podle této logiky:
- Všechny projektové domény mujprojekt.cz/sk/hu atd. by směřovaly jako aliasy do jednoho adresáře
- Na základě domény by se rozhodlo, jestli se použije local.cz.neon, local.sk.neon atd., nikdy by se nepoužíval pouze „local.neon“
- V každém neonu by byly uložené odlišné připojení k databázi.
- Logiku uploadovaných souborů už mám vyřešenou, aby byly uloženy v data/cz, data/sk atd.
- Pokud bych chtěl volat www/index.php přes konzoli, musel bych zadat parametr –domain:mujprojekt.cz
Celou logiku ještě nemám úplně hotovou, ale napadly mě tyto problémy, které mohou nastat:
- Jak zajistit, aby index.php měl přes konzoli parametr –domain? Zkoušel
jsem to, ale když jen přečtu parametry přes $_SERVER[‚argv‘], tak mi to
pak zařve:
The "--domain:localhost" option does not exist. - Jak zajistit, aby composer nehledal local.neon, dá se mu podsunout jiný název config souboru jako parametr?
- Nemohou nastat problémy při cachování? Že když např. přijde nejprve požadavek z mujprojekt.hu, pak přijde požadavek na stejnou podstránku z mujprojekt.cz – nemůže se stát, aby druhý uživatel pak viděl stránku maďarsky, případně aby se neustále neinvalidovala cache? O fungování cache toho moc nevím.
- Mohou nastat nějaké další neočekávané problémy?
- Marek Bartoš
- Nette Blogger | 1179
Imho si zbytečně komplikuješ život. Když chceš mít jazykové verze oddělené, tak je odděl kompletně. Jeden jazyk = jedna instalace projektu. Prostě kód nahraješ do X různých umístění místo jednoho. A žádný ze zmíněných problémů nemusíš řešit.
- Kamil Valenta
- Člen | 764
Marek Bartoš napsal(a):
Prostě kód nahraješ do X různých umístění místo jednoho. A žádný ze zmíněných problémů nemusíš řešit.
A já jen doplním, že ani těch X míst nemusí být potřeba. Kód je na jednom místě – verzovací systém, ať už GIT, nebo jiný. A zda se při releasu dělá deploy do jednoho nebo X míst, už je jedno.
Každopádně fyzické oddělení projektů bude mít mnoho benefitů. Rychlejší routování, snazší zálohování, pozdější možnost rozdělení na více serverů s jiným fyzickým umístěním apod.
- Marek Bartoš
- Nette Blogger | 1179
A zda se při releasu dělá deploy do jednoho nebo X míst, už je jedno.
Však jsem napsal totéž, ne?
Každopádně fyzické oddělení projektů bude mít mnoho benefitů.
Přidám pár dalších důvodů. Při deployi migruješ jednu databázi a ne X. Když spadne jedna instalace, nespadnou všechny. Instalace nemusí být vázaná jen na jazyk – hodně zemí má více oficiálních jazyků (např. Kanada má angličtinu a francoužštinu), hodně zemí mluví anglicky, ale mají rozdílné zákony a dostupnost jednoho serveru může být z různých anglicky mluvících zemí hodně rozdílná.
- dreken
- Člen | 36
mystik napsal(a):
Jak ctes ty argv? Obvykle se pouziva misto : bud = nebo mezera.
Proc by mel composer vubec hledat neon config?
V configu jazykovych verzi si nastav oddelene tmpDir aby se cache nemichaly.
Samozřejmě syntaxe argumentů může být jiná, to už je jedno, problém je, že registrovat argument může pouze služba. To ale nevím, jak udělat před načtením configu.
composer hledá config, protože composer dump mi aktualizuje databázi podle aktuálního schématu.
Editoval dreken (17. 1. 2023 12:39)
- m.brecher
- Generous Backer | 768
@dreken
Nemohou nastat problémy při cachování? Že když např. přijde nejprve požadavek z mujprojekt.hu, pak přijde požadavek na stejnou podstránku z mujprojekt.cz – nemůže se stát, aby druhý uživatel pak viděl stránku maďarsky, případně aby se neustále neinvalidovala cache?
Moc zkušeností s Nette nemám, ale dělám teď na menším vícejazyčném projektu. Vícejazyčné texty které se do šablon latte vypisují proměnnou:
<h1>{$title}</h1> // necachuje se
se necachují, ale vždy se načítají z databáze.
Texty zapsané přímo v šabloně v tagu {translate} se cachují a to tak, že Latte pro každou jazykovou verzi přeloží samostatný soubor:
<h1>{translate}Nadpis{/translate}</h1> // cachuje se
Popisované obavy, že by se jazykové verze v cache úložišti pomíchaly jsou asi zbytečné.
Cachování statických textů v šablonách jsem nedávno řešil, protože v Nette na Windows cachování nefungovalo, ale na serveru s Linuxem ano. Tato drobná chyba je opravena a v poslední vývojové verzi latte/latte:^3.0.5-RC1 funguje cachování i na Nette na Windows.
Ukázka kódu pro cachování překladů statických textů v latte šabloně je v mém příspěvku: https://forum.nette.org/…latte-v3-0-4
Záleží jak složitý je projekt na kterém pracuješ, pokud není velký, myslím, že můžeš jít i mojí cestou ;)
- mystik
- Člen | 293
@dreken Tuhle logiku musis mit uz v bootstrapu, kde se rozhoduje jake configy se nactou a jak se sestavi container. V okamziku, kdy je container uz sestavy je pozde na to ho chtit menit.
Druha moznost by byla napsat si DI extension, ale imho pro tvuj pripad zbytecna.
Proste v bootstrapu podle domeny nebo argv vyberes config a dal jedes standardne.
- m.brecher
- Generous Backer | 768
@MarekBartoš
Imho si zbytečně komplikuješ život. Když chceš mít jazykové verze oddělené, tak je odděl kompletně.
@KamilValenta
A já jen doplním, že ani těch X míst nemusí být potřeba. Kód je na jednom místě – verzovací systém, ať už GIT, nebo jiný. A zda se při releasu dělá deploy do jednoho nebo X míst, už je jedno.
Souhlasím, že u složitějšího projektu se kompletním fyzickým oddělením jazykových verzí získají nepřehlédnutelné benefity. Jak ale naložit s překlady statických textů v latte šablonách? Předpokládám, že ty se budou stejně tak jako tak překládat a cachovat, ale každý server si bude odděleně překládat jen tu svoji jazykovou verzi.
@dreken měl obavy, zda cachování jazykových verzí šablon bude spolehlivě fungovat. Já myslím, že cachování překladů funguje spolehlivě. Je to tak, nebo máte jiný nápad jak texty v šablonách přeložit?