děkuji za pěknou inspiraci. Mohl byste, prosím, rozvinout tu druhou část? Mohl byste mi vysvětlit, jak si představujete tu část s RESTEM? A to s multitenant - "aby se to na jednom serveru dalo provozovat pro víc spolků" - to znamená, že bude jeden server, jedna databáze, do které se budou ukládat všechny ty spolky, informace a další data...
Tedy prakticky: Byl by napsán server ve springu s REST, a potencionální uživatelé by používali tu klientskou část, která by přes AJAX stahovala data ze serveru, že? S tím, že několik spolků může být spravováno v jeden čas.
Díky
Psal jste, že byste použil REST s AJAXem. To zapadá do mé představy, jakou by taková aplikace měla mít architekturu – na backendu Spring, který bude veškeré služby poskytovat přes RESTové API, a jako frontend klasická SPA, která bude volat to RESTové API. Mně by se pro tu frontend část nejvíce líbilo Vue, ale klidně to může být třeba Angular nebo React.
Má poznámka k RESTu pak směřovala k tomu, aby to RESTové API bylo navržené tak, že může fungovat i samostatně, bez té webové aplikace. Často se totiž stává, že když se navrhuje RESTOvé API pro jednu konkrétní SPA, je to API s tou frontendovou aplikací natolik svázané, že prakticky nejde jinde použít. Tady by ale myslím bylo vhodné, aby cokoli, co půjde udělat přes webový frontend, šlo (bez větší námahy) udělat i voláním API. Například klasický postup přidání nového člena spolku by byl takový, že to nějaký administrátor spolku nakliká přes webové rozhraní. Ale spolek už má třeba jinou evidenci a chtěl by používat jiné funkce té aplikace – tak si udělá propojku, která přes to RESTové API bude vytvářet členy na základě toho druhého systému.
Multitenant znamená, že se aplikace provozuje jenom jednou (typicky jen s jednou databází), ale z hlediska uživatelů se to chová, jako kdyby to bylo víc nezávislých aplikací, pro každý spolek jiná. Např. můžete mít jednu instalaci účetního programu, vede se v ní ale účetnictví několika firem. Z pohledu uživatelů se to chová, jako by účetnictví každé firmy bylo zvlášť – nesmí se tedy stát, že by účetní jedné firmy viděl nějaké údaje z jiné firmy, nebo že by si i navzájem mohli jenom měnit konfiguraci.
Nejsnazší by samozřejmě bylo mít pro každou firmu/spolek jinou databázi, jenže to je zejména ve webovém prostředí obtížně řešitelné – pokud byste měl na jednom serveru třeba 100 databází, těžko může server udržovat třeba 400 spojení do databáze (pro každou databázi 4), která by byla většinu času neaktivní. Druhá možnost je mít vše ve společných tabulkách, prakticky v každé tabulce pak tedy musí být i sloupec určující, do které firmy daný záznam patří. Pak je samozřejmě potřeba ve všech dotazech přidávat i podmínku na aktuální firmu, aby se právě nestalo, že se někde zobrazí i údaje někoho jiného. To je jedna nevýhoda, druhá nevýhoda je, že se pak jednotlivé firmy ovlivňují více, než je zdrávo – když budete mít devět firem, každá bude mít deset faktur, a desátá firma bude mít deset tisíc faktur, penalizované za to, že pracují s tabulkou o desetitisíci záznamech (což je tedy pořád málo, ale v jiných tabulkách může být těch záznamů řádově víc), budou všechny firmy. Většina relačních databází pak umožňuje ještě něco mezi, že se připojujete k jedné databázi, ale uvnitř ní je víc prostorů, které jsou do jisté míry oddělené. Třeba v PostgreSQL by se pro tohle dala použít schémata.
Ale zároveň to není věc, která by tam musela být za každou cenu hned od začátku, asi to není věc, která by se řešila na úrovni bakalářské práce. Ale dá se s tím počítat třeba na úrovni API – třeba účetnictví Flexibee to má dělané tak, že první položka cesty v URL je vždy identifikátor firmy. Takže třeba pro seznam faktur Firmy1 voláte
https://www.example.com/firma1/faktury a pro seznam faktur Firmy dva voláte
https://www.example.com/firma2/faktury. Mimochodem zrovna Flexibee má docela pěkné API, ve kterém jde udělat skoro všechno, co umí ta aplikace samotná.
Pokud byste měl nějaké další dotazy, klidně se ptejte. Já budu rád, když taková aplikace konečně vznikne a nebudu jí muset příště psát znova sám :-)
92 Odpovědí
69060 Zhlédnutí