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

6 ferkomatus
položil/-a 10.11. 10:11

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
14 rmaslo
odpověděl/-a 10.11. 17:27

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. 18:32
  • 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. 21:42
  • 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. 1:20
  • 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. 1:45
  • 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. 7:56
  • 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. 11:47
  • 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. 15:05
  • 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. 21:43
  • 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. 22:10

Pro zobrazení všech 4 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.