ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 15
Abonament PDF

Cum am facut primul meu Azure Mobile Service

Florin Cardasim
Head of Architecture & Analysis
@Endava



DIVERSE

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:

  • Timp de dezvoltare pentru backend foarte puțin; nu voiam să investim mai mult de vreo două zile, incluzînd testare și integrare;
  • Modificări cît mai puține în aplicațiile mobile - aici aveam deja "interfața" JSON, deci părea că suntem asigurați;
  • Simplitate la hosting, deployment și configurare;
  • Intenția de a avea suport de push notificațion pentru mai multe platform mobile (iOS, Android, Windows); aici ne așteptam sa fie complicat, dar s-a dovedit a fi de fapt a fi extrem de simplu.

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 !

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects