Více instancí aplikace – rozdělení do subdomén nebo ne?
- krust
- Člen | 14
Ahoj! Mám takovou otázku k zamyšlení a rád se nechám poučit od zdejších kapacit. Řekněme, že mám aplikaci, která by jednou mohla běžet na 200 různých místech. Co už mám rozhodnuté, tak je to, že každé místo má svou DB. K tomu všemu je jedna administrace, která může do všech těchto DB nahlížet.
Otázka ale je, zdali je lepší každou tuhle instalaci dát na vlastní
subdoménu (objekt1.aplikace.cz, objekt2.aplikace.cz…), nebo je lepší to
mít na jedné adrese a po přihlášení uživatele se přiřadí do
frontmodelu patřičná DB? Jde mi o to, jak Nette pracuje a co pro něj bude
lepší? Ať už kvůli cache, počtu najednou přihlášených uživatelů a
podobně.
Děkuji za rady.
- Václav Pávek
- Backer | 97
Z toho jak jsi popsal svoji představu bych to řešil tak, že součástí
aplikace je i administrace.
Přihlásíš se např. na prihlaseni.aplikace.cz kdy součástí
přihlašovacího procesu bude vybrání vhodné (např. nejbližší) aplikace
kam budeš přesměrován s nějakým tokenem a následně si aplikace
ověří, že jsi přihlášen např. pomocí OAuth.
Výhodou tohoto řešení, že vždy nasazuješ aplikaci včetně
administrace a s odpovídajícími databázovými migracemi.
Určitě bych používal subdomény, ale přihlášení je možné pouze na
jednom místě. Bude se to i lépe debugovat a bude to o něco
bezpečnější.
Pokud by jsi to řešil přes DB tak by jsi v aplikaci měl službu
DatabaseResolver která by měla metodu
getDatabase(UserID $userId) a ta by vracela „databázové
spojení“ (nepsal jsi co používáš za DB).
- krust
- Člen | 14
Asi jsme se nepochopili. Konkrétně to mám teď tak, že každá instance aplikace je úplně stejná, jen má vlastní databázi (MySQL), kvůli oddělení dat a běží na vlastní doméně. Dále existuje jedno admin rozhraní, které má vlastní admin databázi, ale může se přepínat mezi jednotlivým dílčími databázemi objektů, aby nahlédla do jejich dat – řekněme supervisor.
Řeším teď otázku těch jednotlivých instancí, kdy buď:
- Bude doména obj1.aplikace.cz pro objekt 1, obj2 pro objekt 2, budou to identické složky, každá ale na vlastní subdoméně
nebo
- prihlaseni.aplikace.cz, kde bude vazba na databázi účtů/objektů, objekt 1 má svůj login a po přihlášení se v modelu napojí jeho databáze pro práci s daty, po přihlášení objektu 2 se zase napojí databáze objektu 2 atd.
Moje otázka byla, jestli je lepší řešení 1 nebo 2, z důvodu že by všechny instance aplikace běžely na jednom místě pouze každá s vlastní databází, nebo jestli je oddělit jak databázově, tak souborově. Řeším to kvůli výkonu atd, protože nevím, co vše se v Nette cachuje apod. Ve skutečnosti budou aplikace na objektu 1,2,3,… fungovat všechny stejně, jen každá ji bude plnit jinými daty. Takže jestli může jedna fyzická aplikace běžet na cca 200 počítačích zároveň, každý účet by byl připojený do jiné databáze. Je tohle realné?
- David Matějka
- Moderator | 6445
- souborově to určitě neoddělovat, nech to jako jednu aplikaci
- jestli subdomény nebo ne je z hlediska nette jedno, na výkon, cachování
atd. to vliv mít nebude. spíš jde o nějaký UX
- když to půjde z jednoho login pointu tak buď musíš nechat uživatele vyplnit i nějaký identifikátor toho objektu, aby se to mohlo připojit do správné databáze, nebo mít ještě oddělenou databázi s uživatelskýma účtama a po přihlášení poznáš, do jaké databáze se to má připojit.
- když to bude na subdoméně, tak můžeš dle ní snadno detekovat kam se to má připojit a nemusíš nijak brát v potaz aktuálního uživatele. dále máš výhodu, že jsou oddělený session, takže člověk se může snadno připojit současně k více „objektům“. a imho i z pohledu uživatele (aspoň advanced) vypadá subdoména víc izolovaná a víc custom