To podmínkování jsme používali i poslední firmě, jen toho pak časem bylo nějak moc. Pokud budu muset do základního/společného modulu, asi to bude právě takto "trapně", stylem IF ()..., ale zatím jsem se tomu ubránil. Nicméně už nyní má každý klient v settings.py USER_ID = "jmeno_klienta", takže to asi jednoho dne nastane.
Spoléhat se na něco, že to vždy vybere správnou DB nechci, takže v settings (ad klient) je konfigurace databáze pro daného klienta. Navíc jsem zůstal u SQLite (jedná se zatím o tisíce řádek denně), neboť miluji, když celý projekt je v souborech. Měj se, Standa On Tuesday, 6 October 2020 at 11:50:34 UTC+2 MirekZv wrote: > Zaujalo mě, že se tady vůbec neprobírá možnost použít Sites framework (ze > základní instalace, contrib.sites). > Pak bys udržoval jeden kód, který by pouze v settings.py dělal: from > konfigurace_tehle_firmy import SITE_ID, a kód by sis větvil: if > SITE_ID=n:... > Resp. pokud v konfiguráku SITE_ID nemáš, tj. máš společný konfigurák pro > více zákazníků, tak Sites framework určí SITE_ID podle domény (url). > Neboli, dávalo by Ti to možnost pro větší zákazníky mít extra instalaci a > extra databázi. > > Jinak s multitenant jsem si něco zkoušel, konkrétně s > django-tenant-schemas, které mají každou kopii databáze jako jedno Postgres > schéma a podle domény (např. podle domény 3.řádu: zakaznik.sluzba.cz) > vyberou schéma, se kterým pracují. > Funguje to, zdá se dobře. > Seznam zákazníků si uděláš do své aplikace např. customer, do tabulky > např. customers.Customer. Je otázka, jestli by to šlo směřovat přímo na > djangové Sites, to asi ne (asi nebudou sedět pole, která má Sites a pole, > která chce django-tenant-schemas), ale neměl by být problém nějak druhotně > určit to SITE_ID, abys mohl větvit kód podle zákazníka, pokud má mít něco > extra. > > No a nebo to zkombinovat nějak jakkoli jinak: třeba nastavené SITE_ID by > znamenalo produkční instalaci, přičemž ta by buď jela přímo (velký > zákazník, vše pro něj extra), nebo s django-tenant-schemas + tabulkou > Customers (malý zákazník, sdílí Postgres cluster). > Kombinace SITE_ID a customers.id by pak dávala unikátní klíč, který > určuje zákazníka. Ten třeba pomocí nějaké tabulky centrální evidence > zákazníků změnit na string, a větvit úplně obyčejně: if > request.zakaznik='TESCO':... > > Napsal jsem schválně request.zakaznik, protože takovou věc je asi vhodné > přiřadit v middlewaru (=vždy). > > > Dne čtvrtek 17. září 2020 v 13:58:49 UTC+2 uživatel Messa napsal: > >> Ahoj, >> >> pár nápadů: >> >> - je fajn si rozmyslet, jestli chceš provozovat pro každého klienta >> samostatnou instanci (kontejner apod.), nebo to mít vše v jedné. Se >> samostatnými instancemi je víc režie, ale zase je např. omezený blast >> radius, pokud se něco u jedné z nich podělá. Samostatné instance bych asi >> řešil jen pokud jich bude třeba do deseti. Na druhou stranu my třeba víc >> instancí toho samého používáme pro škálování (sharding) a pro >> speciální deploymenty pro "VIP klienty", ale všechny instance mají stejný >> kód, jen jinou db. >> >> - chce to trochu software engineering :) Víc git větví bych nedělal, do >> toho se můžeš zamotat, a nebo se v tom pak už nevyzná někdo, s kým bys na >> tom případně spolupracoval. Spíš by tě mohly zajímat feature flagy, design >> patterny pro pluginy, věci trochu víc zapouzdřit, než v Djangu bývá >> běžné... Oddělovat věci do knihoven nebo modulů... Možná se nejdřív >> zamyslet, jak bys to dělal, kdyby to byl normální softwarový projekt (který >> začíná main funkcí a vše řeší explicitně), a pak přijít na to, jak to >> udělat v Djangu :) >> >> - možná by stálo zato to rozdělit do komponent. Např. backend bude >> stejný, frontend se může lišit u každého klienta. Btw. toto teď řeší >> Shoptet Premium, vyšlo o nich pár podcastů, mají zajímavý přístup (ale >> neříkám, že bych to dělal přesně takto). >> >> - asi by ses neměl bránit zlepšování se v devops praktikách :) Když děláš >> takovéhle věci, tak to chce mít infrastrukturu, o kterou se můžeš opřít. >> >> - je otázka, jak naložit s databází (v podstatě pro ni platí ty samé >> úvahy výše, jako pro celou aplikaci), to by chtělo vědět, co tam bude za >> data a jestli/jak se mohou mezi klienty strukturně lišit. Tady mám třeba >> zkušenosti s tím, že jsme na několika místech udělali >> overengineered generalizovaný systém, který by měl teoreticky zvládnout >> jakéhokoliv klienta (resp. jeho data) nějakým univerzálním způsobem, ale >> pak to stejně shořelo na něčem, s čím nikdo vůbec nepočítal :) a takový >> systém pak tvoří zbytečná omezení nebo dokonce hacky (což je paradoxně to, >> čemu měl ten systém zabránit). Takže nakonec máme spíš kód, který na první >> pohled vypadá duplikovaný (což triggeruje programátorské ADHD) ale zase je >> triviálně přehledné, co to dělá a jak se logika liší mezi jednotlivými >> klienty. Mimochodem mě se tady líbí nosql přístup, ve kterém se >> můžeš vyhnout migracím a může být jednodušší pracovat s mnoha "malými" >> databázemi/kolekcemi, včetně operations aspektů; ale nosql a django možná >> není dobrá kombinace. >> >> Jako tohle jsou přesně věci, které když se pokazí, tak rozpočet, kvalita >> kódu a použitelnost projektu jdou přes palubu :) Ale jestli to >> programuješ sám, tak snad nebudeš moc trpět sunken cost syndromem. >> >> Petr >> >> so 12. 9. 2020 v 0:25 odesílatel stanisl...@gmail.com < >> stanisl...@gmail.com> napsal: >> >>> Zdravím, >>> >>> potřeboval bych poradit či navést na best-practice v Django, jak jeden >>> projekt nasadit pro více firem, ale tak, abych v čase mohl dělat klientské >>> modifikace. Aktuálně jsem vymyslel aplikaci a používají ji 2 moji klienti. >>> Django aplikace běží na nGinx a abych mohl obě aplikace aktualizovat >>> současně, na serveru jsem nalinkoval společné zdrojové kódy (virtuál >>> linkuje společné adresáře/aplikace). Vše běží, protože každá aplikace má >>> svou konfiguraci a svou databázi. Pokud aplikaci vylepším, nahraju ji na 1 >>> místo, restartuji server či oba virtuály a oba klienti frčí na >>> aktualizacích. >>> >>> Nicméně: jak nejlépe postupovat, pokud např. 1. firma bude chtít nějakou >>> změnu v šabloně, 2. firma například upravit či přidat celou funkčnost. Rád >>> bych udržel zdrojový kód jednotný s nějakými "odbočkami" pro konkrétního >>> klienta, ale nemohu najít jak nejlépe a nejsystémověji se tomu postavit, >>> aby projekt byl dlouhodobě spravovatelný, zvlášť pokud by přibylo klientů. >>> >>> Věřím, že existuje nějaké systémové řešení, budu rád i za navedení či >>> odkaz na nějaký tutorial. Předem díky! >>> >>> -- >>> >> -- >>> E-mailová skupina djan...@googlegroups.com >>> Správa: http://groups.google.cz/group/django-cs >>> --- >>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny >>> „django-cs“ ve Skupinách Google. >>> >> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, >>> zašlete e-mail na adresu django-cs+...@googlegroups.com. >>> Chcete-li tuto diskusi zobrazit na webu, navštivte >>> https://groups.google.com/d/msgid/django-cs/f508f99c-c9d9-46c4-9ce3-102506cd4634n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-cs/f508f99c-c9d9-46c4-9ce3-102506cd4634n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- E-mailová skupina django-cs@googlegroups.com Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google. Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com. Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/53bc9572-47c5-4bb1-b639-881850ee1467n%40googlegroups.com.
