Asa cum au anuntat de anul trecut, incepand de azi serviciul Account Kit by Facebook se inchide definitiv.
Ati folosit serviciul? Daca da, ce alternativa ati gasit si cum v-a afectat produsul?
Stiu ca Tinder foloseau Account Kit pentru autentificarea userilor.
Inca o lectie pentru cei care n-au invatat nimic dupa inchiderea Parse.
1 Like
Da, si Tinder au folosit Account Kit. Partea buna era ca serviciul era free. Pt aplicatiile care aveau nevoie de verificare nr de tel a fost foarte util.
Cred ca lectia de aici e sa nu ne mai ‘impletim’ codul cu alte librarii si servicii si sa invatam sa folosim design patterns ca Adapter si Facade ca sa putem oricand renunta la ele sau sa le inlocuim.
Multi developeri din lene sau din comodidate isi leaga codul de o librarie si apoi traiesc cu ea de gat doar pentru ca la un moment dat devine foarte greu de renuntat la ea.
Aici nu era vorba de o librarie de network calls sau cache-ing, era mai curand usurinta de a folosi ceva care avea toate flow-urile gata facute, inclusiv partea de UI, cost 0 si a nu implementa de la 0 cu Twilio, de exemplu.
1 Like
Trebuie sa recunosc ca nu am avut tangenta cu Account Kit dar imi e greu sa cred ca toata povestea asta nu poate fi ascunsa in spatele unui Facade, si cand afli ca dispare faci alt Facade si il folosesti alt serviciu sau iti faci propria implementare…
Eu trebuie sa recunosc ca nu sunt adeptul reinventarii rotilor, folosesc tot ce ma poate scuti de munca. Nu pentru ca sunt lenes, dar in ziua de azi e important sa ajungi cu produsul la client ca sa ti-l valideze (sau nu).
Dar da, ma ganesc si la varianta ca la un moment dat nu voi mai fi multumit de o librarie, serviciu, etc si ca e posibil sa lle inlocuiesc. De aceea:
- Orice nu e al meu sta in spatele unei interfete Adapter sau Facade;
- Evit framework-urile si prefer librariile.
@invatamprogramare.ro zici ca ai 12 ani, implementarea la account kit se facea in 3 linii de cod, n-ai nevoie de nicun facade. Toata ideea serviciului era ca te scutea de scris cod, era tot flow-ul de verificare nr de tel implementat de ei si tie iti dadeau doar un webhook cu un token. Dar poate mai important era ca serviciul era free pana in 100.000 de sms-uri trimise pe luna.
Incearca sa nu mai eviti frameworkurile, s-ar putea sa iti fie utile.
1 Like
Îi vorba de eficiență aici. După cum ai citit și în postările de mai sus, atâta timp cât este o librărie free cu tot codul implementat, de ce să cheltui timp și resurse să reinventezi roata? Binenteles, riscul este ca într-o bună zi să nu mai fie disponibilă. Dar cum Facebook a anunțat cu suficient timp înainte, cine utiliza aceea librărie ar fi trebuit să aibă timp să găsească o altă soluție.
1 Like
fix luna trecuta am facut 12 ani (nu glumesc).
Folosesc framework-uri: mvc, orm, di, mvvm dar e bine sa stii ce avantaje ai si la ce riscuri te expui cand le folosesti. Nu toate framework-urile merita riscul si mai bine folosesti o libraire.
1 Like
Imi vine sa te intreb daca stii diferenta intre framework si librarie :))
Diferenta dintre ele este ca o librarie o apelezi tu pe ea ori de cate ori ai nevoie de ea. Pe cand un framework iti creaza un cadru de lucru in care te apeleaza el pe tine si are la baza IoC. Adica, pe de o parte, la un framework ai mai putin control decat la o librarie. Iar pe de alta parte, deoarece framework-ul e cel ce te apeleaza pe tine e mult mai invaziv in codul tau si cand vei vrea sa il inlocuiesti cu altceva iti dai seama ca trebuie rescrisa o buna parte din aplicatie. De aceea eu prefer librariile.
Imaginea din acest articol mi se pare sugestiva: https://medium.com/datafire-io/libraries-vs-frameworks-626cdde799a7 articolul e ok-ish.