Antonia Onaca Povestea aceasta este despre simplitate si robustețe, o alăturare aparent neobișnuită sau cu siguranță greu de realizat în dezvoltarea de aplicații software. Și de fapt aceasta era realitatea cu ani în urmă cînd fiecare își dezvolta propria soluție de backend, propriile mecanisme de comunicație, propriul limbaj de programare, propriul… ce-o mai fi. Platformele Cloud au transformat lumea aceasta complicată într-una unde provocarea cea mai mare este buna înțelegere a lumii în care trăim și a oportunităților de afaceri.
Vă voi povesti cum am redescoperit recent frumusețea cloud-urilor publice: eram în toiul pregătirilor pentru ediția următoare a conferinței IT din Iași - CodeCamp . Site-ul evenimentului (versiunea browser) era pregătit însă nu aveam vesiune pentru mobile, și aceasta e o greșeală într-o lume în care fără prezență pe mobile ești aproape inexistent. Din fericire, comunitățile sunt alcătuite din oameni inteligenți și săritori, așa că fără ca măcar noi (organizatorii evenimentului) să știm, versiunile mobile native erau deja în marketplace (Apple, Google, Microsoft) - și sunt înca acolo, donwloadează-le si alătură-te comunității! "Super!", am zis; "dar de unde își iau aplicațiile acestea datele despre eveniment (speakers, sesiuni, agenda etc)"? Am aflat imediat că prietenii noștri - trebuie să ii laud un pic, excelenți programatori iPhone, Android, Windows Phone - foloseau un fișier static în format JSON în care copiaseră datele de pe site si le mențineau manual dupa fiecare modificare a noastră (și desigur ca apăreau desincronizări). Probabil că agiliștii denumesc aceasta "arhitectură emergentă" Și desigur că am decis să "emergem" în continuare și să construim un backend comun așa cum se cuvine pentru aplicații și site-ul web.
Așa că am început să căutăm o soluție tehnică, avînd vedere următoarele constrîngeri:
Desigur că primul lucru pe care l-am făcut a fost să aruncăm o privire în nori (în Cloud, vroiam să spun). Și am descoerit acolo o ofertă destul de promițătoare, care includea Parse si Windows Azure Mobile Services. Ne-am oprit la a doua, în principal pentru că aveam deja un pic de experiență și o subscripție MSDN cu credit inclus pentru Windows Azure. Haideți să vedem cum a fost mai departe.
Am intrat in portal https://manage.windowsazure.com și după 5 click-uri și sub un minut de așteptare aveam deja serviciul creat, cu toată infrastructura aferentă.
Foarte simplu spus (imaginea de mai sus ajută la înțelegerea conceptelor), serviciul mobil este un set de tabele relaționale într-o bază de date SQL Server, pusă la dispoziție în timpul creării serviciului, accesibile prin servicii HTTP REST care oferă acces CRUD la date formatate JSON, prin intermediul verbelor HTTP - POST (create), GET (read), PATCH (update), DELETE (delete).
Pe baza formatului JSON pe care aplicațiile mobile îl foloseau deja, a fost foarte simplu sa creez în portal tabele precum Events, Locations, Sessions, Speakers, Tracks - locul în care aveau să stea datele. Imediat după popularea cu date (care desigur că se poate face manual, lucru nerecomandat, așa că am făcut o aplicație care împinge datele în tabele din Azure), acestea erau deja disponibile în formatul JSON deja cunoscut de aplicațiile mobile (unde nu a fost nevoie de moficări, exact așa cum ne doream) printr-un call de tipul https://codecampevents.azure-mobile.net/tables/Events.
Desigur că deasupra acestui model de acces la date există un nivel de securitate, aplicabil din portal la nivel de tabel și operație de tip Read, Insert, Update, Delete, nivel care constă în validări pe bază de chei secrete (menținute tot in portal) sau în autentificare folosind sisteme de identitate precum Google, Microsoft, Facebook si Twitter.
Până acum am vorbit doar de creare de tabele și diverse configurări. Dar cum scriu cod în serviciu, care e modelul programatic, cum intervin atunci când vreau să tratez apelurile către serviciu? Răspunsul e evident în imaginea de mai jos unde e descrisă secvența de procesare a cererilor HTTP. Mai întâi acționează nivelul 1, la care nu am acces programatic, e parte din platformă, e locul în care cererea HTTP și conținutul acesteia, inclusiv identități, sunt interpretate, transformate în obiecte Java Script și apoi trimise ca parametri la nivelul Scripting Layer, locul unde pot interveni cu propriul cod. Stai puțin, Java Script?! Ei bine, da - aceste scripturi rulează peste Node JS care e găzduit pe plaformă. De ce Java Script? Probabil pentru că toată lumea îl știe și pentru că avem deja Node JS. Oricum modelul e generos, există API pentru acces la baze de date, apeluri de resurse/servicii HTTP, push notifications către aplicațiile mobile (iOS, Android, Windows Phone și Windows 8), acces la Azure Blob Storage și Service Bus, și mă aștept la lista sa crească. Revenind la Scripting Layer, după procesarea codului scris de mine ca programator, execuția continuă cu nivelul 2, unde obictele Java Script validate, îmbogățite, procesate conform nevoilor aplicației, sunt mapate pe câmpuri din baza de date.
Imaginea de mai jos prezintă interacțiunea dintre aplicațiile mobile, backend și mine însumi care m-am asigurat ca participanții la conferință știu locația, ora de începere și alte informații utile, trimițîndu-le notificări direct pe smart phone prin intermediul serviciului mobil.
Fiecare operație are în spate un script relativ simplu scris în JavaScript, care fie interacționa cu baza date, fie genera notificări de tip push prin intemediul unui API foarte simplu. Restul muncii investite e legată de cîteva configurări banale pentru securitate, notificări, integrare cu Facebook, managementul bazei de date din spatele seriviciului. Ați putea crede căam facut toate astea în mai puțin de două zile? Ei bine, în primul rând au fost nopți, iar in al doilea rând au mai fost cîteva ore în plus pentru rezolvarea unor bug-uri "mind twisting" de Java Script. Dar totul a mers atît de repede nu pentru că aș fi eu un geniu al progamării, ci pentru că plaftorma e foarte clară și simplu de folosit.
Voi incheia prin a vă întreba: ce-am văzut până acum e suficient pentru a spune că avem un serviciu robust, gata pentru medii de producție? N-am spus nimic despre monitorizare, logging, scalabilitate, scheduled tasks și alte funcții obligatorii pentru o aplicație serioasă. Ei bine, toate astea sunt deja acolo, și vă recomand să le încercați !
de Mircea Mare
