Fiind una dintre cele mai mari zone ale industriei IT, cu un procent estimat la aproximativ 35% din aceasta, dezvoltarea de aplicații web oferă o gamă largă de tehnologii și de soluții variate pentru implementarea oricărei nevoi care poate apărea. Pe zi ce trece, aceste opțiuni devin din în ce mai numeroase, ducând poate chiar la o suprasaturare a posibilităților, lucru care poate duce la folosirea unei soluții suboptime pentru nevoia în cauză. Chiar și așa, posibilitățile existente duc, de cele mai multe ori, la apariția unor soluții interesante care ne scot din așa zisa "cutie tradițională de gândire".
În experiența mea recentă, una dintre cele mai interesante abordări de acest tip întâlnite este folosirea unui BPMN ca motor logic al întregii aplicații. Un BPMN Engine (Business Process Modeling Notation Engine) este o unealtă folosită pentru automatizarea fluxurilor de activitate prin construirea unor diagrame "inteligente" și bine definite care ghidează bunul mers al aplicației. Într-o arhitectură stratificată obișnuită, un BPMN ar putea ține rolul unui simplu nivel Business Logic, executând marea parte a logicii din aplicație. Totuși, majoritatea motoarelor BPMN vin cu capabilități mult mai largi, permițând chiar realizarea unei aplicații complete în cadrul BPMN-ului.
Unul dintre punctele forte oferite în cazul dezvoltării integrale a unei aplicații utilizând BPMN-ul este posibilitatea de a crea interfața grafică prin mecanisme simple de "Drag and Drop", aspect promițând o creștere semnificativă a vitezei de dezvoltare pe termen lung.
Spre deosebire de alte platforme care încearcă să ofere alternative de construire a unor site-uri prin simple acțiuni de "drag & drop", un BPMN vine către programator cu un set mai mare de componente de scară mică, care odată îmbinate într-un mod bine gândit, pot să permită o multitudine de acțiuni și să construiască elemente mult mai complexe. Acest mod de lucru este similar cu paradigma de design atomic al frontendului, paradigmă care pune accentul pe cele mai mici elemente (cum ar fi cele simple de input, label, button, radio-button), care se pot îmbina ca niște atomi pentru a crea componente complexe mai mari, numite organisme.
Cu toate acestea, componentele oferite sunt, de cele mai multe ori, rudimentare, ajungându-se la o relativă limitare a lor atunci când vine vorba despre elemente extrem de complexe sau despre pagini web stilizate în moduri foarte specifice. Din experiența avută, domeniul ideal pentru folosirea funcționalității de "drag & drop" este unul care nu necesită un nivel foarte înalt de complexitate vizuală sau comportamentală. Este un domeniu care implică foarte multe date și unde zona de frontend are mai mult rolul unei interfețe prin care utilizatorul doar introduce informații și efectuează operațiuni simple. Un exemplu perfect pentru un astfel de domeniu ar fi cel bancar, unde operațiunile implică un volum mare de date colectate și sunt de cele mai multe ori relativ rudimentare comparativ cu alte zone de activitate. De aceea, tehnologia de BPMN se bucură de o răspândită utilizare în tehnologia financiară, oferind soluții rapide și cu costuri reduse care uneori sunt chiar standardul.
Dorindu-se însă ajungerea la o serie mai largă de domenii, un motor BPMN poate să permită crearea și utilizarea așa numitelor "custom components", componente scrise integral într-o tehnologie web de nivel mai înalt, cum ar fi Angular, care sunt apoi importate și consumate unde este nevoie. Oferind această posibilitate, un BPMN permite unui programator să îi utilizeze funcționalitatea de "drag & drop" la nivel de UI pentru cerințe mult mai diversificate și să vină cu soluții proprii acolo unde este nevoie de acestea.
Fig 1. Exemplu de utilizare a componentelor custom prin BPMN
Prezența acestor componente singulare și utilizarea lor într-un mod decuplat vine la rândul ei cu un impact asupra arhitecturii unei aplicații web care folosește un BPMN "în spate". O astfel de aplicație nu are nevoie de mai multe pagini, de o separare a elementelor în componente inteligente și componente proaste sau de o structură comună de componente părinți și copii. Pentru o astfel de aplicație este de ajuns crearea unei ferestre de vizualizare a conținutului redat de BPMN și a componentelor reutilizabile, care pot să fie grupate sub forma unei librării de elemente, acestea fiind folosite doar prin invocarea și redarea directă din BPMN.
Un alt aspect foarte important care trebuie menționat este că, la bază, un BPMN este valorificat pentru automatizarea sau pentru crearea fluxurilor de activități, aspect care, din nou, în domeniul potrivit poate să fie un mare plus, dar care poate aduce un număr de limitări atunci când un flux continuu nu este întocmai ceea ce este necesar. Pentru a exemplifica conceptul de flux, vom reveni la exemplul dat anterior, domeniul bancar. Acesta este cunoscut pentru liniaritatea proceselor desfășurate, cum ar fi un proces de deschidere a unui cont pentru un client nou, liniaritate care, odată ce este bine definită și separată în etape clare, poate fi foarte ușor reprezentată de o diagrama logică care merge într-o anumită direcție specificată și care bifează niște pași secvențiali.
Luând în calcul ceea ce înseamnă "flux", trebuie avut în vedere și faptul că, la un nivel suficient de înalt și de abstract, orice proces de activitate poate să fie reprezentat printr-o diagramă logica cu pași separați, permițându-se folosirea unui BPMN pentru aproape orice tip de aplicație. Totuși, doar pentru că se poate folosi, nu înseamnă că decizia folosirii este una optimă, aceasta putând chiar uneori îngreuna mult procesul și aduce un nivel adițional de complexitate și de inginerie indus artificial prin mularea cerinței asupra unei diagrame logice secvențiale.
Fig 2. Exemplu de flux semi-liniar simplu
Din perspectiva experienței de utilizator, fluxurile bine definite sunt extrem de utile și scad nivelul de complexitate atunci când sunt folosite pentru procese liniare, dar pot îngreuna o ușoară utilizare a aplicației atunci când cerința nu se pliază optim asupra abordării liniare. Adițional, pentru a avea pașii bine definiți de care o diagramă are de cele mai multe ori nevoie, interfața cu utilizatorul trebuie să rămână adesea relativ sterilă ca experiență și să execute acțiuni cu rol de trecere de la o treaptă la alta în fluxul de activitate.
Pe lângă cele două puncte mai bine cunoscute menționate anterior, din experiența mea, cel mai mare avantaj al folosirii unui BPMN pentru frontend este că acesta poate juca și rolul unei singure surse de adevăr pentru aplicație, un avantaj pe care mulți oameni cu care am discutat despre această tehnologie nu îl apreciază la adevăratul său nivel.
Persistența datelor a reprezentat de-a lungul timpului o problemă pentru aplicațiile web. Cum ar fi ca aceasta să devină o chestie a trecutului? Cum ar fi ca starea aplicației să fie perfect ținută, complet, de la o sesiune la alta, chiar de la un dispozitiv cu care este accesat site-ul la altul? Folosind un BPMN pentru orchestrarea frontendului putem păstra toate datele dintr-un proces de activitate, având mereu o imagine în timp real a stării aplicației, incluzând toate informațiile colectate, toate datele folosite, toate acțiunile făcute de utilizator și toți pașii prin care acesta a trecut în procesul pe care îl execută, fie el unul liniar sau nu.
Cum funcționează asta în spate? Într-un mod destul de simplu de înțeles. La un nivel destul de abstract, putem privi un BPMN ca pe o simplă mașină de stare sau ca pe un model comportamental bine programat pentru fiecare ramură logică pe care să meargă. Într-o diagramă de flux, pașii pe care utilizatorul îi poate face sunt bine definiți, acordând predictibilitatea necesară pentru a controla întreaga aplicație la un nivel macro și pentru a ști mereu ce date vor fi necesare în următoarele etape și ce informații nu mai sunt relevante.
În mod normal dacă un utilizator apasă butonul A, știm că acesta declanșează apariția modalei B. Aceasta, dacă are nevoie de date deja existente, trebuie ori să le ia dintr-un sistem de gestionare a stării aplicației, ori să execute o funcție pentru a lua datele din nou de la backend. Cu un BPMN, toate datele sunt deja în motorul din spate. Când utilizatorul apasă butonul A, diagrama logică deja configurată știe că utilizatorul a trecut într-o etapă nouă a fluxului, etapa în care trebuie să îi fie arătată modala B, lucru gestionat în totalitate de BPMN. Astfel, acesta ia toate datele de care știe că are nevoie din cele pe care deja le are oricum pe fluxul de activitate în cauză, creează modala B, orchestrând construirea ei, o afișează utilizatorului prin fereastra de vizualizare folosită în aplicație web și îi controlează starea pe parcursul perioadei de viață în care trebuie afișată. Utilizatorul a terminat cu modala și urmează sa treacă mai departe în diagramă? În scenariul acesta, modala este distrusă, utilizatorului îi este redat următorul ecran. Iar orice date folosite sau colectate în modală, făcând acum și ele parte din imaginea de pe BPMN, pot să fie ori desconsiderate și șterse sau păstrate și folosite în viitor dacă în diagrama logică se știe posibila nevoie pentru ele.
Fig 3. BPMN funcționând ca singura sursă de adevăr pentru date
Acest avantaj are, de asemenea, și cele mai mari ramificații asupra arhitecturii unei aplicații web, întrucât oferă o simplificare substanțială la mai multe nivele din aceasta. Nu doar că îndepărtează nevoia folosirii unei modalități de gestionare a stării aplicației, cum ar fi tradiționalul Redux sau folosirea unor servicii cu stare menținută, ba chiar poate să înlăture în întregime nevoia de folosire a serviciilor de comunicare cu backendul, toată această comunicare putând să fie mutată în întregime în interiorul BPMN-ului. La nivel de componente, simplificările sunt mai subtile, dar sunt în continuare prezente. Elementele special construite pentru BPMN nu au nevoie de mecanisme de comunicare cu părinții sau cu frații lor, fapt datorat orchestrării realizată de BPMN prin care acesta consuma doar componentele de care este nevoie la momentul respectiv, construindu-le cu toate datele pe care le necesită și injectând în ele acțiunile pe care trebuie să le execute pentru a salva informații sau pentru a reda diferite comportamente alte utilizatorului.
Singura mențiune pentru acest avantaj este faptul că el vine cu o forțare la aderarea la această "singură sursă de adevăr". Odată ce tranziționăm această zonă spre BPMN, nu mai avem posibilitatea de a folosi aplicația de frontend ca pe una normală, fiind neadecvat să mai ținem orice fel de date doar pe frontend. Apeluri normale de tip REST, spre exemplu, pot să fie în continuare executate pentru a aduce date independent, dar acestea ar trebui totuși să fie ulterior trimise către BPMN pentru ca acesta să aibă mereu toate datele utilizabile din aplicație și pentru a putea reda toate ecranele și componentele vizuale într-un mod independent.
Pentru a rezuma, este important să înțelegem că aplicațiile web au ajuns într-un punct în care pot să fie dezvoltate aplicând o multitudine de tehnologii și de unelte, făcând ca cea mai importantă decizie să fie folosirea uneltei potrivite pentru nevoia în cauză.
Valorificată bine, și, poate mai important, în domeniul potrivit, o unealtă de tipul BPMN poate să ducă la o scădere semnificativă a costurilor de dezvoltare și a duratei necesare de finalizare a unei aplicații web. Folosind fluxuri bine definite, funcționalități de "drag & drop" și gestionare independentă a informațiilor, această tehnologie poate facilita o dezvoltare mai bună și aduce și mai multe avantaje decât cele menționate mai sus.
Cu toate acestea, trebuie avut în vedere și faptul că odată folosit, un BPMN impune o serie de constrângeri și de limitări, atât arhitecturale cât și funcționale, care schimbă în întregime "fața" unei aplicații și, care, pentru un domeniu de activitate foarte dinamic, pot să îngreuneze substanțial întregul proces de dezvoltare.