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 [email protected] < > [email protected]> 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 [email protected] >> 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 [email protected]. >> 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 [email protected] 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 [email protected]. Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/1a1b6af6-7cb9-428f-8a5e-03a65b4070d3n%40googlegroups.com.
