správny návrh viacerých verzií jedného systému a API rubrika: Návrh

4 ferkomatus
položil/-a 10.11.2017

v rámci práce, robím na jednom obrovskom systéme (ktorý sa už robí nejaký ten rok a ešte nejaké tie roky bude robiť)
bol zvolený taký postup, že budú vydané 3 verzie systému (aby sa nečakalo X rokov, kým to bude všetko spravené)

verzia Lite, Pro, Enterprise - všetky tieto 3 verzie budú samostatné produkty
Lite verzia je veľmi zjednodušená Pro verzia ... a Pro verzia je zjednodušená Enterprise verzia

návrh Entít je však robený pre Enterprise verziu

v rámci ďalšieho predajného produktu sa bude robiť aj REST API, ktoré má byť spravené pre Enterprise verziu ... a tak sa s ním aj pracuje
Lite a Pro verzia majú údaje získavať cez API ... takže musia mať vlastnú správu viacerých veci, musia robiť X requestov naviac, aby mohli správne vytvoriť konkrétnu entitu

konkrétny príklad:
API pre vytvorenie predstavenia:

POST /performance
- name
- CostCenter
- start_date
- end_date
- Location
- private
- FormatVideo|NULL
- FormatAudio|NULL
- EventVersion|NULL
- EventAccessibility|NULL
- ExpirationType|NULL
- ExpirationValue|NULL
- Vat
- allow_selling
- allow_discounts
- allow_reservations
- Mark|NULL
- Event

v Lite verzií, sa však použije iba:

- name
- CostCenter
- start_date
- end_date
- Location
- private
- Vat
- allow_selling
- Event

popis predstavenia je v entite Event, ktorá vyzerá takto:

- original_name|NULL
- production_year|NULL
- EventType
- description
- genres: []
- roles: []
- origin_countries: []
- premieres: []

v Lite verzií sa pri Event používa iba description a EventType

keďže Lite je niečo samostatné, tak pre vytvorenie predstavenia cez API musí najprv:

  1. zistiť všetky CostCenter a vybrať, ktoré sa použije (robí to lite systém, nie klient)
  2. pred vytvorením Performance, musí najprv vytvoriť Event (robí to lite systém, nie klient)

takýchto veci bude musieť Lite robiť automaticky viacero, keďže ma správne používať API najvyššej verzie

moja otázka znie, je takýto postup návrhu správny ?
alebo by Lite verzia mala používať iné API, prispôsobené práve jej ?

odkaz
12 rmaslo
odpověděl/-a 10.11.2017

Celé to rozdělení na Lite, Pro, Enterprise mi přijde dost nepraktické a spíše takové "obchodnické" než "programátorské" a obávám se, že než se aplikace dodělá tak se obchodnické požadavky mohou změnit a pokud je to zadrátovné do aplikace takovýmto způsobem tak to i může přestat vyhovovat.

Postupoval bych klasicky, tak jak je v oboru zvykem. Tj. vytvořit uživatele, skupiny a práva. Práva se většinou dělají na formuláře jednotlivých agend, ale samozřejmě se mohou nastavovat na tabulky a jak je v tomto případě požadavkem i na jednotlivé sloupce tabulek.
Navíc v této části zadání se o právech uživatelů nemluví, pokud se s nimi počítá, tak vlastně není potřeba nic extra programovat, pokud o nich obchodníci zatím nemluví tak je to jen asi ještě nenapadlo :-). A s takovýmto návrhem jsem připraven i na to, že ze tří verzí udělají dvě nebo čtyři a že to nakonec nebude třeba po sloupcích agendy, ale po agendách (což je mnohem běžnější) atd..

Takže souhlas s Kitem, udělal bych to jako jednu aplikaci (se stejným API) a "verze" řídil právy.

Komentáře

  • ferkomatus : ako som písal, systém je zložitý .. a preto aby sa dostal čím skôr na trh, tak sa okresali funkcie a vznikne LITE a PRO .... ide mi skôr o tože pri LITE bude musieť robiť API requesty naviac, ktoré by nemuselo robiť ... a či je to vôbec celkovo dobrý návrh 10.11.2017
  • Kit : Můžeš mít 3 různé serverové implementace, ale API a klienta bys měl udělat stejné. LITE by těch requestů mělo naopak dělat méně. 10.11.2017
  • rmaslo : I API lez upgradovat a pokud je to navrženo tak, že nová verze API umí vše to stará (zpětná kompatibilita) tak to nebývá problém. Tj. API verze 1. vrací množinu sloupců "Lite". API verze 2. obecně vrací množiny sloupců "Lite" + "Pro". Ale pro uživatele u1 vrací i API v. 2 množinu sloupců "Lite" protože na "Pro" nemá právo. 12.11.2017
  • rmaslo : PS: Navíc se obávám, že "móda práv dle sloupců" teprve přijde. Dneska se totiž (podle mě, aspoň v malých podnicích) moc neřeší, že když si třeba ve výrobě potřebují zobrazit objednávku tak se jim prostě zobrazí včetně všech údajů. Ale s příchodem přiblblého GDPR se jim sloupec e-mail nebude moci zobrazovat (je to osobní údaj a oni ho nepotřebují) a možná bude dokonce "povinnost dokázat, že se jim zobrazit nemůže". Což podle mě lze snad jedině tím, že skupina výroba na něj nemá db práva ani ke čtení. 12.11.2017
  • ferkomatus : rmaslo ono asi až teraz som to pochopil ... (predtým som sa nad tým až tak nezamýšlal) ... áno cleý systém bude mať práva na rôzne funkcionality a už teraz je možné nastaviť právo na konkrétne entity a akcie nad entitami ... ale moja otázka ostáva tá istá, asi nezodpovedaná: Majú byť 3 verzie API ? alebo 1 verzia API ? keďže štruktúra DB je pripravená na Enterprise, no Lite všetko z toho nevyužije ... ak by som to mal všetko nastavovať cez práva, potom by museli existovať 3 verzie práv .. typu: LITE_PERFORMANCE_READ, LITE_PERFORMANCE_CREATE .... PRO_PERFORMANCE_CREATE, PRO_PERFORMANCE_DELETE .... 12.11.2017
  • rmaslo : @ferkomatus: Podle mě jedna verze (nebo nekonečně mnoho verzí - to je věc pohledu), ale prostě API neexpoertuje ty sloupce ke kterým nemá uživatel práva. To jestli nemá práva protože má verzi LITE nebo jestli nemá práva protože není ve správné skupině i třeba verze PRO je podle mě nepodstatné. 12.11.2017
  • Taco : @ferkomatus: Mělo by stačit jen READ a CREATE. A pak ten uživatel, který k tomu přistupuje dostane od ACLka správná práva podle toho, zda má Lite, nebo Pro verzi. Určitě bych to nekomplikoval. Pro a Lite není otázka architektury. 12.11.2017
  • ferkomatus : len ono mne tu nejde o stlpce/dáta ... ale skôr o FUNKCIE/AKCIE nad entitou ... v jednoduchej verzií sa s tým má teoreticky pracovať JEDNODUCHO ... a že je to v DB zapísané zložitejšie to je už iná vec 12.11.2017
  • Kit : @ferkomatus: Tak zkus i v té verzi Pro a Enterprise udělat jednoduché funkce/akce nad entitou. Ve verzi Lite je uděláš tak, aby procedury nic nedělaly a funkce nevracely hodnoty. Přesněji slepé procedury a funkce budou vyhazovat výjimky. API to nijak neovlivní, to bude jednotné. 12.11.2017
  • archenroot : jedna se o field level authorization. existuji systemy hlavne v relacnich databazich, ktere to implementuji, jeena se o tzv VPD, vyhoda je, ze je to rychle. data se filtruji primo nad storage a vystup uz je orezany. je to omezene a narocne, protoze to delas mimo sluzbu. spise to uvadim, ze jsem to delal pred 4 lety...no a jak to udelat na api vrstve? spring data rest to bohuzel zatim plne nepodporuje pokud se nepletu viz issue DATAREST-428 nicmene existuje framework, ktery ano Jello framework. pokud se bavime o jave Update: ted jsem si docetl celou komunikaci a vidim, ze vam nejde o autorizaci k datum, resp. ta nevyresi ten problem s lite/pro/enterprise... samotneho by me zajimal optimalni navrh jak tohle poresit. 1.12.2017
  • Kit : @archenroot: Když to uděláš na DB vrstvě, je to mnohem jednodušší. Na aplikaci nemusíš změnit ani čárku. Ve verzi Lite do databáze nahraješ dummy funkce, procedury a pohledy. Pokud si někdo zakoupí vyšší licenci, nahradíš je plnotučnými. 1.12.2017
  • archenroot : @Kit Ze by to bylo jednodussi to bych ani nerekl, je to proste presunuti urciteho mechanismu na jinou vrstvu, ja jsem to(vpd) delal na db vrstve, jak jsem psal, a bylo to hlavne kvuli vykonu, data sla ven uz odfiltrovna, ne ze se vypumpovala cela a pak na middlewaru se filtrovala. Ale jak rikam, napr. Postgres ma vpd stale omezenou, ja to stavel na oracle 11, ale napr. oracle 12 prinesl super rozsireni, granularita sla komplet na cell level. Jako me se to samozrejme libi, ale posledni roky delam na high performance event driven microservice architekturach (situace 10,000 requestu za vterinu s response limitem pod pul sekundy -> event sourcing, sagas, CQRS, audit patterny) a veskera bezpecnost a business logika je drzena na urovni sluzeb, database je "jen dummy" data store. CQRS mi oddeluje write a read modely. Read model je lokalni instance sluzby materializovana z event storu, v pripade destrukce nebo poskozeni muzu Read modely prehrat z event storu jako film ve video prehravaci... to popisuju jen jako kontext veci, na kterych pracuju, ale jak to souvisi. Jde o to, ze Read model(to je Q z CQRS patterny) je lokalni embedded databaze (mongodb nebo postgresql) managovana primo z JVM (yandex embedd postgres) a pro pripojeni nepouzivam TCP protokol, ale unix sockety, coz prinasi brutalni zrychleni (dej si hledat: postgresql unix socket vs tcp), zhruba 2x z pohledu transakci i latence. Takze ja podobne filtery resim proste na urovni sluzby, nemusim resit java kod a slq kod(ja uz nepisu vlasne zadny sql kod), sluzba a db instance (pouze pro cteni) je jeden vydeplojovany micromonolith. Ale neznam architekturu fermokatuse do detailu, takze ano, v jeho pripade muze byt db cesta lepsi. Jde o to, ze "klasicke old fashion" projekty maji databazovou vrstvu oddelenou bezici na nejakem clusteru... ja uz bych to dnes na db vrstve nestavel, ale v jeho pripade proc ne. 1.12.2017
  • Kit : @archenroot: No jo, ale když nad tou databází napíši další aplikaci třeba i v jiném jazyce, tak budu muset znovu implementovat stejnou business vrstvu. Nedejbože, kdybych ji napsal odlišně nebo kdyby se během života těch aplikací udělaly vzájemně nekompatibilní změny. To by byl docela průšvih, ne? 1.12.2017
  • archenroot : V mikrosluzbach muzes psat kazdou sluzbu, nebo i metodu (ve forme deployovatelne sluzby) v jinem jazyce, ale nasledujes jedno pravidlo, sluzba se stara o svoji domenu a je jejich jedinym spravcem a pokud mozno pristupovim bodem. Tvuj pristup neni uplne koser v DDD principech aplikovanych na mikrosluzby. Ale jak rikam, a souhlasim s tebou, pokud mas jednu databazi a budes psat 4 aplikace v jinych jazicich, ktera ty data potrebuji, tak ano, to je koser, ale ne v mikroservice architekturach, jsou data dalsim sluzbam klidne napsanych v jinych jazycich k dispozici pouze pres sluzbu, ktera je vlastnikem domeny. Vstupnim bodem uz neni databaze, ale sluzba. Databaze slouzi jen jako uloziste dat, a muze byt take poskytovana jako sluzba 2.12.2017
  • Kit : @archenroot: Když umístím službu, která je vlastníkem domény, do databáze, mohu se k ní připojovat z mnoha různých klientů a nehrozí mi nekonzistence dat v databázi. Pokud bych chtěl použít databázi jen jako úložiště dat, zvolím NoSQL, které je pro tento účel vybaveno lépe. 2.12.2017
  • archenroot : Jestli je to SQL nebo NoSQL neni podstatne, proste data v ni ulozena jsou zpristupnena pouze pres rozhrani sluzby, ta data filtruje podle nejakych ACL, nebo rozepis to trochu, ted jsem to moc nepochopil. Diky. 2.12.2017
  • Kit : To rozhraní služby prostě implementuješ v databázi včetně ACL. Není potřebná žádná další aplikační nezivrstva. Aplikace tak s databází může komunikovat přímo. 2.12.2017
  • archenroot : Jo jasne, at uz custom nebo vpd jak jsem psal, ale v mikroservisech s timhle nepochodis stejne. Protoze tak jak kazda sluzba (aplikace) muze byt napsana v jinem jazyce, tak stejne kazda muze pouzivat jinou databazi pro read/query modely pro svoji domenu,jedna postgres, jedna mongodb, dalsi elasticsearch... , nebo je to pak o kompromisech, definujes jednotny jazyk projektu a nejak napr. omezis database choices, jedna pro sql, jedna pro nosql a end of story... kompromisy... protoze nakonec to znamena, ze tenhle ACL, nebo jak to nazvat aplikuje kazda sluzba jinak, jedna na db, jedna na app vrstve, chapes :-))). 2.12.2017
  • archenroot : Kit - jeste k tvemu prispevku vyse "Přesněji slepé procedury a funkce budou vyhazovat výjimky", tak to je to posledni, co bych delal, ukazovat uzivateli neco, co nemuze pouzivat... jinak ten koncept VPD a ACL ktery tu diskutujeme stejne neni to, co uplne ten clovek potrebuje, ale diky za pokec, protoze me to zajima. Nize jsem navrhnul separatni prispevek, kde resim puvodni zadani i s kodem, pripadne poznamky welcomed. 2.12.2017

Pro zobrazení všech 5 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.