Dacă nu ai API, nu exişti.
Am putea nuanța această afirmație categorică afirmând că fără API nu exişti în cloud, pentru a lansa apoi interogația: oare poţi exista în afara cloud-ului, în zilele noastre?
Probabil gândiţi: frumoasă compilare de cuvinte în vogă pentru a începe articolul. Vă mulţumesc! Şi sper ca restul articolului să fie la fel de atrăgător sau mai puţin respingător, în funcţie de preferinţa dumneavoastră pentru cuvinte la modă.
Lăsând gluma la o parte, aţi investi într-un startup care ignoră cloud-ul şi nu are API? Eu ştiu că nu aş face-o. Giganţii din software sunt de acord.
Mai trebuie să mărturisesc şi faptul că ideea aceasta nu mi-a venit mie. Prima dată am auzit-o de la Mac Devine, CTO al Cloud Services la IBM. Acesta era în faţa unei audienţe la conferinţa CloudOpen de anul trecut, vorbind despre cum să creezi o primă companie ce oferă servicii cloud şi făcea mereu referire la acest aspect. Dacă nu ai API, ceilalţi nu pot utiliza date de la tine şi nu pot să interacţioneze cu tine, adică este ca şi cum nu ai exista.
Mai auzim multe şi despre noul stil de IT şi puterea dezvoltatorilor. Este într-adevăr o perioadă grozavă pentru a fi dezvoltator. Toată puterea de decizie este transferată, iar dezvoltatorii au mult mai multe de spus în legătură cu tehnologia care este utilizată. Acest lucru a mers atât de departe încât se transmite acum şi în mediile de enterprise. Unele organizaţii au dus aceasta deja până la extrem, permiţând dezvoltatorilor să facă schimbări şi să le introducă în producţie de mai multe ori pe zi, după cum doresc.
Dar ce înseamnă aceasta, în realitate? Este de fapt chiar simplu. Trebuie să ai API-uri bune. Chiar foarte bune. Tipul de API pe care ceilalţi pur şi simplu să nu poată rezista să nu le utilizeze. Bineînţeles, ajută şi dacă serviciul tău este valoros de asemenea, dar indiferent cât este el de valoros, de precis şi demn de încredere, dacă este greu să dezvolţi folosind API, dezvoltatorii, având toată puterea de decizie, vor decide să nu îl utilizeze, sau, şi mai rău, nici nu îl vor observa. V-aţi speriat deja? Ar trebui. Acea documentaţie lungă pentru care aţi alocat atât de mult timp ca să o scrieţi şi să o întreţineţi, nu va ajuta. Toată lumea ştie că dezvoltatorii sunt făpturi leneşe, până într-atât încât consideră aceasta o virtute. Şi acesta este numai încă un exemplu al puterii lor. Ei nu vor citi toată documentaţia voastră, de fapt, se poate ca ei să citească cel mult primul paragraf, sau numai titlurile şi să se aştepte ca să o poată încerca imediat şi să o înţeleagă imediat. Iar dacă nu pot, vor trece mai departe, pentru că ei sunt dezvoltatori foarte deştepţi, cu experienţă şi putere, iar dacă nu pot înţelege API în cinci minute, voi aţi făcut ceva greşit. Şi ştiţi ceva? Au dreptate. De ce să nu fie aşa? La urma urmelor, voi sunteţi în competiţie pentru atenţia lor cu alţi furnizori.
API nu sunt deloc ceva nou. Ele au existat de la începutul anilor 2000 şi chiar mai înainte de asta, dacă luăm în considerare nu numai web API.
Vă puteţi gândi la altceva decât la REST atunci când vă gândiţi la API? Nu prea mulţi oameni mai fac acest lucru. Iar motivul este că acestea erau perturbatoare. Simplitatea lor i-a atras pe dezvoltatori. Toată lumea a început să le utilizeze şi să le aleagă, în defavoarea alternativelor mai complexe. Nu ar fi frumos să ai agerimea minţii şi să anticipezi "următorul REST"?
Este foarte atrăgător să inovezi prin simpla prefixare a unei tehnologii cu negaţia "no". SQL este o tehnologie a trecutului? Vine NoSQL să ne salveze! Este tot ca SQL, dar diferită. Atunci, de ce nu noAPI?
De ce să nu luăm API cu caracteristicile lor cele mai bune, dar să le facem mai uşor de utilizat? Să oferim ceva care de asemenea să facă posibilă manipularea şi consumul de date şi servicii, dar care să fie mai uşor de înţeles pentru un dezvoltator. Nu este o API, este o noAPI.
De cele mai multe ori, nu ne mai pasă de particularităţile unei API; nu implementăm totul. Avem language bindings. Este o îmbunătăţire, dar este suficient? Toată lumea preferă să le utilizeze, sunt logice, dar la sfârşitul zilei, language bindings nu sunt nimic mai mult decât reutilizare de cod. Reutilizarea codului este bună, dar, pentru uşurinţa utilizării, putem face mai mult. Soluţia există, şi a existat de ceva vreme; de fapt, s-ar putea să o ştiţi deja şi să o fi utilizat fără să vă gândiţi.
Domain Specific Languages (DSL) - (Limbajele Specifice Domeniului) se potrivesc de minune la aceasta. Ele sunt considerate a fi o formă de API în sensul tradiţional. DSL este un termen pe care îl folosim pentru a descrie un limbaj de programare conceput cu o anume problemă în minte, spre deosebire de limbajele de programare pentru scopuri generale, cu care suntem obişnuiţi. Scopul său este să semene foarte mult cu domeniul respectiv, facilitând gândirea şi rezolvarea de probleme în acel domeniu. Regular expression sunt un limbaj specific domeniului. Le folosim deoarece este mult mai uşor decât să implementăm aceeaşi funcţionalitate într-un limbaj cu scop general. Cu cât este mai complexă potrivirea tiparelor care trebuie făcută, cu atât mai uşor devine să nu implementezi ceva tradiţional. Deoarece limbajul este apropiat de domeniu, este uşor de utilizat.
Să analizăm un exemplu în care oferim un DSL în loc de API. Să presupunem că dorim să configurăm un VM într-un mediu virtual. Un VM simplu, fără şabloane, fără OS instalat. Implementarea pentru această operație ar putea arăta aşa:
#!java
// [...]
backingFile = new VMDiskBackingFile("/path/to/some/file/in/data/store")
bakingFile.setThinProvisioned(true)
disk = new Disk(backingFile)
disk.setParavirtalization(true)
disk.setSizeGB(16)
VMService.createDisk(disk)
vm = new VirtualMachine()
vm.setRamGB(2)
vm.setDisk(disk)
VMService.createVM(vm)
vm = VMService.getVM(vm.getName())
VMService.startVM(vm)
// [...]Se impun anumite observaţii. În primul rând, aţi putea spune că interfaţa API furnizată, pe care o utilizăm, ar putea fi mai bine concepută. Cu siguranţă poate fi îmbunătăţită. Realitatea este, totuşi, că este obişnuit să vezi API ca acestea şi nu e uşor să le îmbunătăţeşti, cât timp le păstrezi modulare, rapide şi generice.
În al doilea rând, sunt multe lucruri pe care dezvoltatorul trebuie să le reţină. Să creeze fişierul înainte de disc şi discul înainte de VM. E important de menționat: trebuie să obţii înapoi informaţiile despre VM înainte de a-l putea porni. Eu unul, nu am încredere în mine că voi reţine toate acestea, deci, ce putem face?
Să luăm în considerare următoarele:
#!
vm {
disk : 2.GB, backigFile "/path/to/some/file/in/data/store" { thinProvisioned },
ram: 2.GB,
power: on
}Să presupunem că aveţi mai mulţi furnizori pentru interfaţa voastră virtuală: primul cu API din primul exemplu; al doilea, cu DSL din al doilea exemplu. Pe care l-aţi prefera?
Aţi observat cea mai importantă diferenţă? Cu DSL, dezvoltatorul nu trebuie să se concentreze pe "cum", ci numai pe "ce". Aceasta este o mare uşurare; îi permite minţii să se concentreze mult mai bine. Este ca şi cum ţi-ar citi mintea.
Dacă consideraţi că este prea mult efort şi că nu merită, rămâneţi cu mine în partea a treia (şi cea finală) a articolului. Este mai uşor decât credeţi.
Implementarea unui DSL poate părea intimidantă la început. Dar vă prezentăm mai întâi un mod simplu de a-l implementa.
JVM este casa multor limbaje de programare, pe lângă Java. Unii susţin că este şi mai important decât limbajul în sine. Groovy este unul dintre aceste limbaje. Este un limbaj de scripting, cu o sintaxa compatibilă cu Java, probabil denumit astfel numai din cauză că JavaScript era luat. Majoritatea codului Java este compatibil cu Groovy, dar nu orice cod Groovy este compatibil cu Java. Şi aici lucrurile devin ciudate. El poate să fie atât de diferit încât programatorii Java nici măcar să nu îl recunoască. De fapt, poate fi atât de exotic, încât este greu de recunoscut chiar şi faptul că este Groovy.
Să fim cinstiţi, Groovy este un limbaj de programare groaznic pentru multe lucruri. Este foarte bun pentru implementarea DSL. Se spune pe website-ul lor că suportă DSL, dar este aproape ca şi cum întregul limbaj ar fi fost conceput numai pentru acest scop unic.
Partea bună este că se integrează dintr-o bucată cu Java, aşa că poţi oricând să implementezi parte din ceea ce vrei în Java, dacă doreşti, şi să foloseşti Groovy numai pentru DSL.
Aria de acoperire a modelului de programare meta Groovy depăşeşte cuprinsul acestui articol. Are într-adevăr o curbă de învăţare, dar nu este excesiv de dificil, odată ce începi să te deprinzi cu el. Partea bună este că e productiv dacă lucrezi cu el; făcând cea mai mare parte de muncă, deci, curba de învăţare merită.
Ca un bonus în plus, DSL devine subansamblu al Groovy. Aceasta înseamnă că poţi oricând să amesteci Groovy în DSL dacă vrei. Obţii date şi structuri de control în DSL pe gratis. Există câteva proiecte grozave care implementează DSL cu Groovy. Unul dintre preferatele mele este Gradle, care implementează un DSL pentru compilarea și asamblarea proiectelor. Este destul de complex, dar un exemplu foarte bun pentru o implementare.
La un nivel înalt, DSL este utilizat pentru a crea un model al domeniului în faza iniţială de configurare când DSL este executat. Apoi, lucrul specific domeniului se execută numai după ce modelul este complet. Aceasta permite execuţiei să decidă în legătură cu ceea ce trebuie făcut, ştiind tot ce trebuie realizat. În exemplul de mai devreme, aceasta ar însemna că serviciul cunoaşte configuraţia completă şi particularităţile VM înainte ca aceasta să înceapă să fie creată. Mai există încă multe alte modalităţi grozave şi rapide de a implementa DSL. Cele mai multe limbaje de programare dinamice pot fi utilizate într-o oarecare măsură.
Nu mai este necesar să începi implementarea unui DSL prin implementarea unui parser.
data viitoare când este nevoie de o API, veţi lua în considerare noAPI?
de Larisa Goța
