Mihail Salosin (mĂ« poshtĂ« â MS): â PĂ«rshĂ«ndetje tĂ« gjithĂ«ve! UnĂ« quhem Mihail. Punoj si zhvillues backend nĂ« kompaninĂ« MC2 Software dhe do t'ju tregoj pĂ«r pĂ«rdorimin e Go nĂ« backendin e aplikacionit mobil 'Shiko+'.
A ka ndonjë nga krijuesit që do të donte hockey?
AtĂ«herĂ« ky aplikacion Ă«shtĂ« pĂ«r ju. ĂshtĂ« pĂ«r Android dhe iOS, dhe shĂ«rben pĂ«r tĂ« parĂ« transmetimet e ngjarjeve tĂ« ndryshme sportive online dhe nĂ« regjistrim. Gjithashtu, aplikacioni ofron statistika tĂ« ndryshme, transmetime tekstore, tabelat pĂ«r konferencat, turnetĂ« dhe informacion tjetĂ«r tĂ« dobishĂ«m pĂ«r tifozĂ«t.
Gjithashtu, në aplikacion ka një gjë të tillë si momentet video, dmth. mund të shihni momentet më interesante të ndeshjeve (golat, përleshjet, penalltitë etj.). Nëse nuk dëshironi të shihni të gjithë transmetimin, mund të shihni vetëm ato që janë më interesante.
ĂfarĂ« u pĂ«rdor nĂ« zhvillim?
Pjesa kryesore është shkruar në Go. Ai API, me të cilin komunikonin klientët mobilë, është shkruar në Go. Gjithashtu, shërbimi për dërgimin e njoftimeve push në mobil është shkruar gjithashtu në Go. Na duhej të shkruanim ORM tonë, për të cilin ndoshta do të flasim ndonjëherë. Po ashtu, disa shërbime të vogla, si rishikimi dhe ngarkimi i imazheve për anën e editorëve, janë shkruar në Go...
Si bazë të dhënash përdorëm «Postgres» (PostgreSQL). Ndërfaqja për editorët është shkruar në Ruby on Rails me ndihmën e gem-it (gem) ActiveAdmin. Po ashtu, importimi i statistikave nga ofruesi i statistikave është shkruar në «Ruby».
PĂ«r testet sistemike tĂ« API-t, pĂ«rdorĂ«m unittest-in e «Python-it» (Python). Memcached pĂ«rdoret pĂ«r tĂ« menaxhuar kĂ«rkesat API tĂ« pagesave, «Chef» â pĂ«r kontrollin e konfiguracionit, Zabbix â pĂ«r mbledhjen dhe monitorimin e tĂ« dhĂ«nave statistikore tĂ« brendshme tĂ« sistemit. Graylog2 â pĂ«r mbledhjen e log-Ă«ve, Slate â kjo Ă«shtĂ« dokumentacioni i API-t pĂ«r klientĂ«t.
Zgjedhja e protokolit
Problemi i parë me të cilin u përballëm: na duhej të zgjedhim protokollin e bashkëpunimit mes backend-it dhe klientëve mobilë, duke u bazuar në pikat e mëposhtme...
- Kërkesa kryesore: të dhënat për klientët duhet të përditësohen në kohë reale. Kjo do të thotë se të gjithë ata që po shikojnë transmetimin në atë moment duhet të marrin përditësime praktikisht menjëherë.
- Për thjeshtësim, e pranuam se të dhënat që sinkronizohen me klientët nuk fshihen, por shfaqen me anë të flamujve të veçantë.
- Kërkesat e rralla (si statistikat, përbërjet e ekipeve, statistikat e ekipeve) merren përmes kërkesave të zakonshme GET.
- Për më tepër, sistemi duhej të përballonte lehtësisht 100 mijë përdorues njëkohësisht.
Duke u bazuar në këtë, kishim dy opsione për protokollin:
- Websocket. Por nuk na duhej kanale nga klienti te serveri. Na duhej vetëm të dërgonim përditësime nga serveri te klienti, kështu që websocket ishte një variant i tepërt.
- Ngjarjet e Dërguara nga Serveri (SSE) ishin perfekte! Ato janë mjaft të thjeshta dhe përmbushin në thelb të gjitha nevojat tona.
Ngjarjet e DĂ«rguara nga Serveri
Disa fjalë rreth mënyrës se si funksionon kjo gjë...
Ajo punon mbi lidhjen http. Klienti dërgon një kërkesë, serveri përgjigjet me Content-Type: text/event-stream dhe nuk e mbyll lidhjen me klientin, por vazhdon të shkruajë të dhëna në lidhje:
TĂ« dhĂ«nat mund tĂ« dĂ«rgohen nĂ« formatin e rĂ«nĂ« dakord me klientĂ«t. NĂ« rastin tonĂ«, ne i dĂ«rguam nĂ« kĂ«tĂ« mĂ«nyrĂ«: nĂ« fushĂ«n event dĂ«rgohej emri i strukturĂ«s qĂ« kishte ndryshuar (njeri, lojtar), ndĂ«rsa nĂ« fushĂ«n data â JSON me fushat e reja, tĂ« ndryshuara pĂ«r lojtarin.
Tani për mënyrën se si funksionon vetë ndërveprimi.
- Së pari, klienti përcakton se kur ishte hera e fundit kur u realizua sinkronizimi me shërbimin: ai shikon në bazën e të dhënave lokale dhe përcakton datën e fundit të ndryshimit të regjistruar prej tij.
- Ai dërgon një kërkesë me këtë datë.
- Në përgjigje, ne i dërgojmë të gjitha azhurnimet që kanë ndodhur që nga kjo datë.
- Pas kësaj, ai krijon një lidhje me kanalin live dhe nuk e mbyll deri sa i nevojiten këto azhurnime:
Ne i dĂ«rgojmĂ« njĂ« listĂ« ndryshimesh: nĂ«se dikush shĂ«non njĂ« gol â ne ndryshojmĂ« rezultatin e ndeshjes, nĂ«se ndodhi njĂ« lĂ«ndim â gjithashtu dĂ«rgohet nĂ« kohĂ« reale. NĂ« kĂ«tĂ« mĂ«nyrĂ«, nĂ« rrjedhĂ«n e ngjarjeve tĂ« ndeshjes, klientĂ«t marrin menjĂ«herĂ« tĂ« dhĂ«nat e sakta. PeriudhĂ«risht, qĂ« klienti tĂ« kuptojĂ« se serveri nuk ka vdekur, qĂ« nuk ka ndodhur asgjĂ« me tĂ«, ne dĂ«rgojmĂ« çdo 15 sekonda njĂ« timestamp â qĂ« tĂ« dijĂ« se gjithçka Ă«shtĂ« nĂ« rregull dhe nuk ka nevojĂ« tĂ« ripĂ«rfitohet.
Si ndihmohet lidhja live?
- Së pari krijojmë një kanal, në të cilin do të vijnë përditësimet me një buffer.
- Pas kësaj, regjistrojmë këtë kanal për të marrë përditësimet.
- Vendosim header-in e duhur, në mënyrë që klienti ta dijë se gjithçka është ok.
- Dërgojmë ping-un e parë. Thjesht regjistroni timestamp-in aktual të lidhjes.
- Pas kësaj, në një cikël lexojmë nga kanali deri sa kanali i përditësimeve të mbyllet. Në kanal herë pas here vjen ose timestamp-i aktual, ose ndryshimet, të cilat ne tani i regjistrojmë në lidhjet e hapura.
Problemi i parĂ« me tĂ« cilin u pĂ«rballĂ«m ishte si vijon: pĂ«r çdo lidhje tĂ« hapur me klientin krijonim njĂ« timer, i cili tikonte çdo 15 sekonda â kĂ«shtu qĂ« nĂ«se kishim 6 mijĂ« lidhje tĂ« hapura me njĂ« makinĂ« (me njĂ« API-server), krijoheshin 6 mijĂ« timer-a. Kjo çonte nĂ« atĂ« qĂ« makina nuk mbante ngarkesĂ«n e kĂ«rkuar. Problemi nuk ishte aq i dukshĂ«m pĂ«r ne, por na ndihmuan pak dhe e zgjidhĂ«m.
Si rezultat tani ping-u vjen nga të njëjtin kanal nga i cili vjen përditësimi.
Për rrjedhojë, ka vetëm një timer, i cili tikon çdo 15 sekonda.
KĂ«tu janĂ« disa funksione ndihmĂ«se â dĂ«rgimi i titujve, pingut dhe strukturĂ«s vetĂ«. Pra, kĂ«tu kalon emri i tavolĂ«s (person, ndeshje, sezon) si dhe informacioni pĂ«r kĂ«tĂ« regjistĂ«r:
Mekanizmi i dërgimit të azhurnimeve
Tani pak rreth burimeve tĂ« ndryshimeve. Ne kemi disa persona, redaktorĂ«, tĂ« cilĂ«t ndjekin transmetimin nĂ« kohĂ« reale. Ata krijojnĂ« tĂ« gjitha ngjarjet: dikush Ă«shtĂ« hequr, dikush ka pĂ«suar lĂ«ndim, ka pasur njĂ« ndĂ«rrimâŠ
Me ndihmën e CMS-së, të dhënat hyjnë në bazë. Pas kësaj, baza me ndihmën e mekanizmit Listen/Notify njofton serverët API. Serverët API tashmë dërgojnë këtë informacion te klientët. Ashtu, ne në thelb kemi vetëm disa serverë të lidhur me bazën dhe nuk ka ndonjë ngarkesë të veçantë në bazë, sepse klienti nuk ndërvepron drejtpërdrejt me bazën:
PostgreSQL: Listen/Notify
Mekanizmi Listen/Notify nĂ« «PostgreSQL» lejon njoftimin e abonentĂ«ve pĂ«r ngjarjet rreth ndonjĂ« ndryshimi â njĂ« regjistĂ«r Ă«shtĂ« krijuar nĂ« bazĂ«. PĂ«r kĂ«tĂ«, ne kemi shkruar njĂ« trigger dhe njĂ« funksion tĂ« thjeshtĂ«:
Kur bëhet një insert ose ndryshimi i një regjistri, ne thërrasim funksionin notify në kanalin data_updates, duke dërguar emrin e tabelës dhe identifikuesin e regjistrit që u ndryshua ose u insertua.
Për të gjitha tabelat që duhet të sinkronizohen me klientin, ne përcaktojmë një trigger, i cili pas ndryshimit/aktualizimit të regjistrit thërret funksionin e specifikuar në slajdin e mëposhtëm.
Si abonohet API për këto ndryshime?
Krijohet njĂ« mekanizĂ«m Fanout â ai dĂ«rgon mesazhe te klientĂ«t. Ai mbledh tĂ« gjithĂ« kanalet e klientĂ«ve dhe shpĂ«rndan pĂ«rditĂ«simet qĂ« ka marrĂ« nĂ« kĂ«to kanale:
Këtu është biblioteka standarde pq, e cila lidhet me bazën dhe thotë se dëshiron të dëgjojë kanalin (data_updates), kontrollon nëse lidhja është e hapur dhe gjithçka është në rregull. Unë po e anashkaloj kontrollin e gabimeve për të kursyer hapësirë (moskontrollimi është i rrezikshëm).
Më pas ne asinkronikisht caktuam një Ticker, i cili do të dërgojë ping çdo 15 sekonda, dhe fillojmë të dëgjojmë kanalin për të cilin jemi abonuar. Nëse marrim një ping, e publikojmë këtë ping. Nëse marrim ndonjë regjistër, atëherë e publikojmë këtë regjistër për të gjithë abonentët e këtij Fanout.
Si funksionon Fan-out?
Në gjuhën shqipe, kjo përkthehet si «devidor». Ne kemi një objekt që regjistron abonentët që duan të marrin ndonjë përditësim. Dhe sa herë që ka një përditësim për këtë objekt, ai e shpërndan atë përditësim për të gjithë abonentët që ka. Mjaft e thjeshtë:
Si është realizuar në Go:
Ka njĂ« strukturĂ« qĂ« sinkronizohet me pĂ«rdorimin e Mutexâave. Ajo ka njĂ« fushĂ« qĂ« ruan gjendjen e lidhjes Fanout me bazĂ«n, domethĂ«nĂ« pĂ«r momentin ajo Ă«shtĂ« duke dĂ«gjuar dhe do tĂ« marrĂ« pĂ«rditĂ«sime, si dhe listĂ«n e tĂ« gjithĂ« kanaleve ekzistuese â njĂ« hartĂ«, e cila ka si çelĂ«s kanal dhe si vlerĂ« njĂ« strukture (nĂ« thelb, ajo nuk pĂ«rdoret pĂ«r asnjĂ« qĂ«llim).
Dy metoda â Connected dhe Disconnected â lejojnĂ« qĂ« Fanout tĂ« dijĂ« se kemi njĂ« lidhje me bazĂ«n, se ajo ka filluar dhe se lidhja me bazĂ«n Ă«shtĂ« ndĂ«rprerĂ«. NĂ« rastin e dytĂ«, duhet tĂ« çaktivizohet tĂ« gjithĂ« klientĂ«t dhe t'u thuhet atyre se nuk mund tĂ« dĂ«gjojnĂ« mĂ« dhe qĂ« duhet tĂ« rishtyn lidhjen, pasi lidhja me ta Ă«shtĂ« mbyllur.
Ka gjithashtu një metodë Subscribe, e cila shton një kanal në «dëgjuesit»:
Ka është një metodë Unsubscribe, e cila heq kanalin nga dëgjuesit nëse klienti është shkëputur, si dhe një metodë Publish, e cila lejon të dërgosh një mesazh për të gjithë abonentët.
Pyetja: â ĂfarĂ« pĂ«rcillet pĂ«rmes kĂ«tij kanali?
MC: â PĂ«rcillet modeli qĂ« ka ndryshuar ose njĂ« ping (nĂ« thelb thjesht njĂ« numĂ«r, integer).
MC: â Mund tĂ« dĂ«rgosh çfarĂ«do, çdo strukturĂ« â ajo thjesht kthehet nĂ« JSON dhe mbaron.
MC: â Ne marrim njĂ« njoftim nga "Postgres" â ai pĂ«rmban emrin e tabelĂ«s dhe identifikuesin. Duke pĂ«rdorur emrin e tabelĂ«s, kemi nevojĂ« pĂ«r identifikuesin pĂ«r tĂ« marrĂ« regjistrimin e nevojshĂ«m dhe pastaj e dĂ«rgojmĂ« kĂ«tĂ« strukturĂ« pĂ«r publikim.
Infrastruktura
Si duket kjo nga pikĂ«pamja e infrastrukturĂ«s? Ne kemi 7 serverĂ« fizikĂ«: njĂ«ri prej tyre Ă«shtĂ« plotĂ«sisht dedikuar pĂ«r bazĂ«n, ndĂ«rsa nĂ« gjashtĂ« tĂ« tjerĂ«t operojnĂ« virtualkĂ«. Ka 6 kopje tĂ« API: çdo virtualkĂ« me API funksionon nĂ« njĂ« server fizik tĂ« veçantĂ« â kjo Ă«shtĂ« pĂ«r besueshmĂ«ri.
Ne kemi dy frontendĂ«, ku Ă«shtĂ« instaluar Keepalived pĂ«r tĂ« pĂ«rmirĂ«suar disponueshmĂ«rinĂ«, qĂ« nĂ« rast tĂ« ndonjĂ« problemi, njĂ« frontend mund tĂ« zĂ«vendĂ«sojĂ« tjetrin. Gjithashtu â dy kopje tĂ« CMS.
Ka Ă«shtĂ« gjithashtu njĂ« importues statistike. Ka DB Slave, nga i cili bĂ«hen periudha backup-i. Ka Pigeon Pusher â kjo Ă«shtĂ« aplikacioni qĂ« dĂ«rgon njoftime push pĂ«r klientĂ«t, si dhe gjĂ«ra infrastrukturore: Zabbix, Graylog2 dhe Chef.
NĂ« tĂ« vĂ«rtetĂ«, kjo infrastrukturĂ« Ă«shtĂ« e tepĂ«rt sepse 100 mijĂ« mund tĂ« shĂ«rbehen edhe me njĂ« numĂ«r mĂ« tĂ« vogĂ«l serverĂ«sh. Por hardueri ishte aty â ne e pĂ«rdorĂ«m (na thanĂ« se ishte e mundur â pse jo).
Pikat pozitive të Go
Pas punës në këtë aplikacion, u shfaqën disa pika të dukshme pozitive të Go.
- Një bibliotekë http e shkëlqyer. Me të, mund të krijoni shumë gjëra që janë gati "nga paketa".
- Për më tepër, kanalet që na lejuan të zbatojmë shumë lehtë mekanizmin e dërgimit të njoftimeve për klientët.
- NjĂ« gjĂ« e shkĂ«lqyer, detektori i garave na ndihmoi tĂ« eliminojmĂ« disa defekte kritike (infrastruktura nĂ« staging). Ădo gjĂ« qĂ« funksionon nĂ« staging Ă«shtĂ« e ekzekutuar, e kompiluar me çelĂ«sin Race; dhe ne, pĂ«rkatĂ«sisht, mund tĂ« shohim nĂ« infrastrukturĂ«n nĂ« staging pĂ«r problemet e mundshme qĂ« kemi.
- Minimalizmi dhe thjeshtësia e gjuhës.
Ne po kĂ«rkojmĂ« zhvillues! NĂ«se ndokush dĂ«shiron â ju lutem.
Pyetje
Pyetja nga audienca ( mĂ« pas â P): â MĂ« duket se keni humbur njĂ« moment tĂ« rĂ«ndĂ«sishĂ«m nĂ« lidhje me Fan-out. A e kuptoj saktĂ« se kur i dĂ«rgoni njĂ« klienti pĂ«rgjigje, ju bllokoheni, nĂ«se klienti nuk dĂ«shiron tĂ« lexojĂ«?
MC: â Jo, ne nuk bllokohemi. NĂ« radhĂ« tĂ« parĂ«, gjithçka ndodhet pas nginx-it tonĂ«, pra nuk ka probleme me klientĂ«t e ngadalshĂ«m. NĂ« radhĂ« tĂ« dytĂ«, klienti ka njĂ« kanal me buffer â nĂ« thelb ne mund ta vendosim atje deri nĂ« njĂ«qind pĂ«rditĂ«sime... NĂ«se nuk arrijmĂ« tĂ« shkruajmĂ« nĂ« kanal, ai e fshin. NĂ«se shohim qĂ« kanali Ă«shtĂ« bllokuar, ne thjesht do ta mbyllim kanalin, dhe gjithçka â klienti do tĂ« rikonkektohet nĂ«se ka ndonjĂ« problem. Prandaj, nĂ« kĂ«tĂ« rast nuk ka bllokime.
M: â A nuk do tĂ« ishte mĂ« mirĂ« tĂ« dĂ«rgonit direkt regjistrimin nĂ« Listen/Notify, nĂ« vend tĂ« id-çështjes sĂ« tabelĂ«s?
MC: â Listen/Notify ka njĂ« kufizim prej 8 mijĂ« byte pĂ«r preload-in qĂ« dĂ«rgon. NĂ« parim, mund tĂ« dĂ«rgojmĂ«, nĂ«se do tĂ« kishim tĂ« bĂ«nim me njĂ« sasi tĂ« vogĂ«l tĂ« dhĂ«nash, por mĂ« duket se ashtu [siç e bĂ«jmĂ« ne] Ă«shtĂ« thjesht mĂ« e besueshme. Kufizimet janĂ« nĂ« vetĂ« 'PostgreSQL'-in.
M: â A marrin klientĂ«t pĂ«rditĂ«sime pĂ«r ndeshjet qĂ« nuk i interesojnĂ«?
MC: â NĂ« thelb, po. NĂ« pĂ«rgjithĂ«si, aty zhvillohen 2-3 ndeshje paralelisht, dhe kjo ndodh goxha rrallĂ«. NĂ«se klienti po ndjek diçka, zakonisht Ă«shtĂ« ajo ndeshje qĂ« Ă«shtĂ« nĂ« zhvillim. MĂ« pas, klienti ka njĂ« bazĂ« lokale, nĂ« tĂ« cilĂ«n tĂ« gjithĂ« kĂ«to pĂ«rditĂ«sime ruhen, dhe madje edhe pa u lidhur me internetin, klienti mund tĂ« shikojĂ« tĂ« gjitha ndeshjet e kaluara pĂ«r tĂ« cilat ka pĂ«rditĂ«sime. NĂ« esencĂ«, ne sinkronizojmĂ« bazĂ«n tonĂ« nĂ« server me bazĂ«n lokale tĂ« klientit, nĂ« mĂ«nyrĂ« qĂ« ai tĂ« mund tĂ« punojĂ« edhe offline.
M: â Pse e bĂ«ret ORM tuaj?
Aleksej (njĂ« nga zhvilluesit e âShiko+â): â NĂ« atĂ« kohĂ« (kjo ndodhi para njĂ« viti) kishte mĂ« pak ORM sesa tani, kur janĂ« mjaft shumĂ«. Nga shumica e ORM-ve ekzistuese, mĂ« sĂ« shumti nuk mĂ« pĂ«lqen se shumica e tyre funksionojnĂ« me interface bosh. KĂ«shtu qĂ« metodat e kĂ«tyre ORM-ve janĂ« tĂ« gatshme tĂ« pranojnĂ« gjithçka: struktura, tregues strukture, numra, diçka krejtĂ«sisht jashtĂ« kontekstit...
ORM ynë gjeneron struktura në bazë të modelit të të dhënave. Vetë. Dhe për këtë arsye, të gjitha metodat janë të qarta, nuk përdorin refleksion etj. Ato pranojnë struktura dhe presin të përdorin ato struktura që do të vijnë.
M: â Sa shumĂ« njerĂ«z morĂ«n pjesĂ«?
MC: â NĂ« fazĂ«n fillestare morĂ«n pjesĂ« dy persona. Diku nĂ« qershor filluam, nĂ« gusht ishte gati pjesa mĂ« e madhe (versioni i parĂ«). NĂ« shtator ishte publikimi.
M: â Atje ku pĂ«rshkruani SSE, nuk pĂ«rdorni timeout. Pse kĂ«shtu?
MC: â NĂ«se flasim hapur, SSE Ă«shtĂ« njĂ« protokoll html5: standardi SSE Ă«shtĂ« i destinuar pĂ«r komunikim me shfletuesit, sa kam kuptuar. Ai ka funksione shtesĂ«, qĂ« shfletuesit mund tĂ« ri lidhin (dhe tĂ« tjera), por ato nuk na duheshin, sepse kishim klientĂ« qĂ« mund tĂ« realizonin çdo logjikĂ« tĂ« lidhjes dhe marrjes sĂ« informacionit. Ne bĂ«mĂ« mĂ« shumĂ« jo SSE, por diçka tĂ« ngjashme me SSE. Nuk Ă«shtĂ« protokolli vetĂ«.
Nuk kishte nevojë. Sa kam kuptuar, klientët realizuan mekanizmin e lidhjes pothuajse nga zero. Ishin të padashur në thelb.
M: â ĂfarĂ« mjete shtesĂ« keni pĂ«rdorur?
MC: â Kryesisht kemi pĂ«rdorur govet dhe golint, pĂ«r tĂ« pasur njĂ« stil tĂ« njĂ«jtĂ«, si dhe gofmt. AsgjĂ« mĂ« shumĂ« nuk kemi pĂ«rdorur.
M: â Me çfarĂ« keni bĂ«rĂ« debugging?
MC: â Debugging nĂ« thelb u zhvillua me ndihmĂ«n e testeve. AsnjĂ« debager, GOP nuk e kemi pĂ«rdorur.
M: â A mund tĂ« kthej Ă©ventin ku Ă«shtĂ« realizuar funksioni Publish? A ju shqetĂ«sojnĂ« emrat e variablave me njĂ« shkronjĂ«?
MC: â Jo. Ata kanĂ« njĂ« "fushĂ«" tĂ« mjaftueshme tĂ« ngushtĂ«. Nuk pĂ«rdoren askund pĂ«rveç kĂ«tu (pĂ«rveç brendĂ«sive tĂ« kĂ«saj klase), dhe Ă«shtĂ« shumĂ« kompakt â merr vetĂ«m 7 rreshta.
M: â Si duket, nuk Ă«shtĂ« shumĂ« intuitiv...
MC: â Jo, jo, ky Ă«shtĂ« njĂ« kod i vĂ«rtetĂ«! ĂĂ«shtja nuk Ă«shtĂ« stili. Thjesht Ă«shtĂ« njĂ« klasĂ« kaq utilitare, e vogĂ«l â ka vetĂ«m 3 fushĂ« brenda klasĂ«s...
MC: â NĂ« thelb, tĂ« gjitha ato tĂ« dhĂ«na qĂ« sinkronizohen me klientĂ«t (ndeshjet sezonal, lojtarĂ«t), nuk ndryshojnĂ«. NĂ« mĂ«nyrĂ« tĂ« pĂ«rgjithshme, nĂ«se do tĂ« bĂ«jmĂ« njĂ« sport tjetĂ«r ku do tĂ« nevojitet tĂ« ndryshojmĂ« ndeshjen, thjesht do t'i marrim parasysh tĂ« gjitha nĂ« versionin e ri tĂ« klientit, dhe versionet e vjetra tĂ« klientit do tĂ« bllokohen.
M: â A ka ndonjĂ« paketĂ« tĂ« jashtme pĂ«r menaxhimin e varĂ«sive?
MC: â Ne pĂ«rdorĂ«m go dep.
M: â NĂ« temĂ«n e prezantimit kishte diçka pĂ«r video, por nĂ« prezantim nuk ka video.
MC: â Jo, unĂ« nuk kam asgjĂ« nĂ« temĂ«n pĂ«r video. E quajtur "Shiko+" â kĂ«shtu quhet aplikacioni.
M: â MĂ« thatĂ« se transmetohet te klientĂ«t?..
MC: â Ne kemi punuar me video streaming. Kjo Ă«shtĂ« bĂ«rĂ« plotĂ«sisht nga «Megafon». Po, nuk thashĂ« se aplikacioni Ă«shtĂ« nga Megafon.
MC: â Go â pĂ«r dĂ«rgimin e tĂ« dhĂ«nave â pĂ«r faturat, pĂ«r ngjarjet e ndeshjes, statistikat⊠Go Ă«shtĂ« krejtĂ«sisht backend pĂ«r aplikacionin. Klienti duhet tĂ« dijĂ« ndonjĂ«herĂ« se cilin lidhje tĂ« pĂ«rdorĂ« pĂ«r player-in, nĂ« mĂ«nyrĂ« qĂ« pĂ«rdoruesi tĂ« mund tĂ« shohĂ« ndeshjen. Ne kemi lidhje pĂ«r video dhe pĂ«r stream-et qĂ« janĂ« pĂ«rgatitur.
Pak reklamĂ« đ
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendrĂ«n e tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m kĂ«tu nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
