Enkonduko
Cifereca transformo kovras pli kaj pli da malsamaj areoj de vivo kaj komerco ĉiujare. Se entrepreno volas esti konkurenciva, ordinaraj informejoj ne plu sufiĉas, necesas moveblaj kaj ret-aplikoj, kiuj ne nur provizas uzantojn per informoj, sed ankaŭ permesas al ili plenumi iujn funkciojn: ricevi aŭ mendi varojn kaj servojn, provizi ilojn.
Ekzemple, ne plu sufiĉas por modernaj bankoj havi retejon kun informoj; ili devas havi interretajn ilojn por siaj klientoj, personan konton, kie la uzanto povas administri kontojn, investojn kaj pruntojn. Eĉ malgrandaj entreprenoj bezonas oportunajn ilojn por pliigi konvertiĝojn, kiel rendevuon kun kuracisto aŭ frizisto, aŭ mendi tablon ĉe restoracio aŭ infana ludĉambro por naskiĝtaga festo.
Kaj la posedantoj mem bezonas ricevi ĝustatempajn informojn en oportuna formo pri la stato de sia kompanio, ekzemple, la kolekto de statistikaj datumoj kaj analizoj por malsamaj produktadsekcioj, aŭ la produktiveco de fakoj. Ofte, ĉiu fako kolektas ĉi tiujn datumojn laŭ sia maniero, kaj eĉ povas uzi malsamajn ilojn kaj la posedanto bezonas pasigi multe da persona tempo por kompreni ĉion ĉi, nerekte aŭ rekte ĉi tio povas influi la efikecon de la kompanio kaj finfine profiton. Ĉi tie ankaŭ helpos cifereca transformo kaj disvolviĝo de retejo aŭ poŝtelefona aplikaĵo.
Teknologioj ne staras kaj senĉese evoluas, kaj tio, kio estis uzata antaŭ pluraj jaroj, eble ne plu estas aktuala hodiaŭ, aŭ tio, kion oni ne povis fari antaŭ pluraj jaroj, jam fariĝis realaĵo. Estas pli modernaj iloj, kiuj helpas vin krei retajn kaj moveblajn aplikojn pli rapide kaj pli bone. Surbaze de personaj observoj kaj sperto, mi volas konigi mian vizion pri kiuj teknologioj kaj iloj estos postulataj en proksima estonteco kaj kial vi devas atenti ilin kiam vi kreas modernan TTT-aplikaĵon.
Unupaĝa aplikaĵo
Ni iom difinu la terminologion. Ununura Paĝa Apliko (SPA) estas retejo, kies komponantoj estas ŝarĝitaj unufoje sur unu paĝo, kaj la enhavo estas ŝarĝita laŭbezone. Kaj kiam moviĝas inter sekcioj de la aplikaĵo, la paĝo ne reŝargiĝas tute, sed nur ŝarĝas kaj montras la necesajn datumojn.
Unupaĝaj aplikoj multe profitas el klasikaj TTT-aplikoj laŭ rapideco kaj facileco de uzo. Kun la helpo de SPA, vi povas atingi la efikon de retejo funkcianta kiel aplikaĵo sur labortablo, sen rekomencoj kaj gravaj prokrastoj.
Se antaŭ kelkaj jaroj unupaĝaj aplikaĵoj praktike ne subtenis serĉilon-optimumigo kaj estis uzataj ĉefe por krei personajn kontojn kaj administrajn panelojn, hodiaŭ krei unu-paĝan aplikaĵon kun plena subteno por serĉilo-optimumigo (SEO) fariĝis multe pli facila. Uzante servil-prezentitajn unupaĝajn aplikaĵojn hodiaŭ, ĉi tiu problemo tute malaperis. Alivorte, ĉi tio estas la sama unu-paĝa aplikaĵo, sed laŭ la unua peto, la servilo generas ne nur datumojn, sed kreas HTML-paĝon pretan por montri kaj serĉiloj ricevas pretajn paĝojn kun ĉiuj meta-informoj kaj semantika markado. .
Kun la disvolviĝo de iloj por krei klientflankajn TTT-aplikaĵojn, la evoluo kaj transiro al unupaĝaj aplikoj nur kreskos en ĉi tiu kaj postaj jaroj. Se vi havas malnovan aplikaĵon, kiu estas malaktuala kaj funkcias malrapide, kaj eĉ kun kompleta paĝa reŝargo kiam vi ŝanĝas inter sekcioj, tiam ĉi-jare vi povas sekure ĝisdatigi al rapida unupaĝa aplikaĵo - nun estas bona tempo, teknologio jam permesas vin. fari tion sufiĉe rapide kaj efike.
Havi modernan kaj rapidan retejon estas tre bona, sed mi diru al vi honeste: ne ĉiuj aplikaĵoj povas esti facile konvertitaj al unupaĝaj aplikaĵoj, kaj la transiro povas esti multekosta! Tial vi devas kompreni, kiu bezonas tian transiron kaj kial.
Por helpi vin kompreni, en la suba tabelo mi donos kelkajn ekzemplojn pri kiam disvolvi aŭ ŝanĝi al SPA estas taŭga kaj pravigita, kaj kiam ĝi ne estas.
POR
Se vi volas fari modernan, rapidan aplikaĵon kaj volas uzi ne nur la retan version, sed ankaŭ la poŝtelefonan aŭ eĉ labortablan version, kaj ĉiuj procezoj kaj kalkuloj okazas sur fora aŭ nuba servilo. Plie, por ke ĉiuj klientoj havu unu interagadan interfacon kaj ne necesas fari ĉiun redakton al la servila kodo aldonante novan klienton.
Ekzemple: socia reto, agregantoj, SaaS-platformoj (programaro kiel nuba servo), foiroj
Se vi havas butikon aŭ retservon, vi scias, ke ĝi malrapidas kaj homoj foriras, vi volas fari ĝin pli rapide, vi komprenas la valoron de klientoj kaj pretas pagi pli ol milionon da rubloj por ĝisdatigo.
Vi havas poŝtelefonan aplikaĵon, kiu uzas la API de la retejo, sed la retejo estas malrapida kaj havas kompletajn enhavajn reŝargojn kiam moviĝas inter paĝoj.
KONTRA.
Se via celita publiko ne uzas modernajn foliumilojn kaj aparatojn.
Ekzemple: specifaj kompaniaj areoj, kiel la disvolviĝo de internaj sistemoj por bankoj, medicinaj institucioj kaj edukado.
Vi faras viajn ĉefajn agadojn eksterrete kaj ne pretas provizi ajnajn servojn interrete, kaj vi nur bezonas altiri klientojn.
Se vi havas interretan vendejon aŭ retservon, kiu jam bone vendas, vi ne vidas klientan elfluon aŭ plendojn.
Se vi havas funkciantan aplikaĵon, kiu ne povas esti adaptita por SPA kaj vi nur bezonas reverki ĉion de nulo kaj uzi aliajn teknologiojn, kaj vi ne pretas elspezi plurajn milionojn por ĉi tio.
Ekzemple: Estas boksita retejo aŭ ia hejme verkita antikva, monolita kodo.
Progresemaj Retaj Aplikoj
Progresemaj Retaj aplikoj estas la produkto de la komuna evoluo de indiĝena aplikaĵo kaj retejo. Esence, ĉi tio estas TTT-apliko, kiu aspektas kaj kondutas kiel vera denaska aplikaĵo, povas ricevi puŝajn sciigojn, labori en eksterreta reĝimo, ktp. En ĉi tiu kazo, la uzanto ne bezonas elŝuti la aplikaĵon de la AppStore aŭ Google Play, sed simple konservi ĝin al la labortablo.
Kiel teknologio aŭ aliro al evoluo, PWA disvolviĝas ekde 2015, kaj lastatempe akiris grandegan popularecon en la elektronika komerco.
Kelkaj realvivaj ekzemploj:
- pasintjare, la hotelo Best Western River North povis pliigi enspezon je 300% post lanĉo de nova retejo ebligita de PWA;
- Araba Avito OpenSooq.com, post kreado de PWA-subteno en sia retejo, povis pliigi la tempon de vizitado de la retejo je 25% kaj la nombro da kondukoj je 260%;
- la fama rendevua servo Tinder povis redukti la ŝarĝan rapidon de 11.91s al 4.69s disvolvante PWA; krome, la aplikaĵo pezas 90% malpli ol sia denaska Android-ekvivalento.
La fakto, ke indas atenti ĉi tiun teknologion, ankaŭ indikas la fakto, ke unu el la plej grandaj motoroj por krei retkomercajn projektojn, Magento, lanĉis fruan evoluan version de PWA Studio en 2018. La platformo permesas krei React-bazitan fasadon el la skatolo por viaj elektronikaj komercaj solvoj kun PWA-subteno.
Konsilo por tiuj, kiuj jam havas interretan projekton aŭ nur ideon pri nova servo kun subteno por porteblaj aparatoj: ne rapidu verki plenrajtan denaskan aplikaĵon, sed unue rigardu la teknologion PWA. Ĉi tio povas esti la plej bona solvo por mono por via produkto.
Iom de praktiko. Por krei simplan denaskan moveblan novaĵ-aplikaĵon, kondiĉe ke vi jam havas pretan REST-servilon, vi bezonas proksimume 200-300 homhorojn per platformo. Kun la averaĝa merkata prezo por horo de disvolviĝo estas 1500-2000 rubloj/horo, aplikaĵo povas kosti ĉirkaŭ 1 milionon da rubloj. Se vi disvolvas TTT-aplikaĵon kun plena subteno por PWA: puŝaj sciigoj, eksterreta reĝimo kaj aliaj bonaĵoj, tiam la disvolviĝo daŭros 200-300 homhorojn, sed la produkto tuj estos disponebla en ĉiuj platformoj. Tio estas, ŝparado de proksimume 2 fojojn, sen mencii la fakton, ke vi ne devos pagi kotizojn por lokigo en aplikaĵbutikoj.
Servilo
Ĉi tio estas alia moderna aliro al evoluo. Pro la nomo, multaj homoj opinias, ke ĉi tio estas vere senservila disvolviĝo, ne necesas skribi malantaŭan kodon, kaj ĉiu antaŭfina programisto povas krei plentaŭgan TTT-aplikaĵon. Sed tio ne estas vera!
Dum kreado de Senservila aplikaĵo, vi ankoraŭ bezonas servilon kaj datumbazon. La ĉefa diferenco de ĉi tiu aliro estas, ke la malantaŭa kodo estas prezentita en formo de nubaj funkcioj (alia nomo por senservilo estas FaaS, funkcias kiel servo aŭ Funkcioj-as-a-Servo) kaj permesas al la aplikaĵo skali rapide kaj rapide. facile. Kreante tian aplikaĵon, la programisto povas koncentriĝi pri komercaj problemoj kaj ne pensi pri skalo kaj agordo de la infrastrukturo, kiu poste akcelas aplikaĵan disvolviĝon kaj reduktas ĝian koston. Krome, la Senservila aliro helpos vin ŝpari sur servilaj luoj, ĉar ĝi uzas ekzakte tiom da rimedoj kiom necesas por plenumi la taskon, kaj se ne estas ŝarĝo, tiam servila tempo tute ne estas uzata kaj ne estas pagita.
Ekzemple, la granda usona amaskomunikila kompanio Bustle povis redukti gastigajn kostojn je pli ol 60% kiam ŝanĝiĝis al Serverless. Kaj la kompanio Coca-Cola, disvolvinte aŭtomatan sistemon por vendi trinkaĵojn per vendiloj, povis redukti gastigajn kostojn de 13000 4500 USD al XNUMX XNUMX USD jare ŝanĝante al Senservilo.
Dum la pasintaj du jaroj, pro sia noveco kaj ĝiaj limigoj, Serverless estis ĉefe uzata por malgrandaj projektoj, noventreprenoj kaj MVP-oj, sed hodiaŭ, danke al la evoluo de programaro, la ĉiuflankeco kaj potenco de servila kontenerigo, emerĝas iloj, kiuj permesas vin forigi limigojn, simpligi kaj akceli la disvolviĝon de nubaj aplikaĵoj.
Ĉi tio signifas, ke entreprenaj komercaj scenaroj kie nuba modernigo antaŭe estis konsiderata neebla (ekzemple, por randaparatoj, datumoj en trafiko aŭ ŝtataj aplikoj) nun estas realo. Bonaj iloj, kiuj montras multan promeson, estas kNative kaj Senservila entrepreno.
Sed malgraŭ ĉio ĉi, Serverless ne estas arĝenta kuglo por disvolviĝo de TTT-apliko. Kiel ĉiu alia teknologio, ĝi havas siajn avantaĝojn kaj malavantaĝojn, kaj vi devas elekti ĉi tiun ilon kun kompreno, kaj "ne marteli najlojn per mikroskopo" nur ĉar ĝi estas pli progresinta teknologie.
Por helpi vin eltrovi ĝin, jen kelkaj ekzemploj de kiam vi eble volas konsideri Serverless kiam vi disvolvas novan aŭ plibonigas nunan retservon:
- Kiam la ŝarĝo sur la servilo estas perioda kaj vi pagas por neaktiva kapacito. Ekzemple, ni havis klienton kun reto de kafmaŝinoj kaj necesis prilabori petojn kaj kolekti statistikojn nur kelkcent aŭ mil fojojn tage, kaj nokte la nombro da petoj falis al kelkaj dekoj. En ĉi tiu kazo, estas multe pli efika pagi nur por la efektiva uzo de rimedoj, do ni proponis kaj efektivigis solvon sur Serverless;
- Se vi ne planas plonĝi en la teknikajn detalojn de la infrastrukturo kaj tropagi por starigi kaj prizorgi servilojn kaj ekvilibron. Ekzemple, kiam vi disvolvas vendoplacon, vi ne scias precize, kio estos la trafiko, aŭ inverse - vi planas multan trafikon kaj por ke via aplikaĵo certe eltenos la ŝarĝon, tiam Serverless estas bonega elekto.
- Se vi bezonas plenumi iujn fluajn eventojn en la ĉefa aplikaĵo, skribu flankajn datumojn en tabelojn, faru kelkajn kalkulojn. Ekzemple, kolektu analizajn datumojn de uzant-agoj, prilaboru ilin en certa maniero kaj konservu ilin en datumbazo;
- Se vi bezonas simpligi, unuigi aŭ akceli la nunan funkciadon de la aplikaĵo. Ekzemple, kreu plibonigajn servojn por labori kun bildoj aŭ filmetoj, kiam la uzanto alŝutas videon al la nubo, kaj aparta funkcio pritraktas transkodigon, dum la ĉefa servilo daŭre funkcias normale.
Se vi bezonas prilabori eventojn de triaj servoj. Ekzemple, procesi respondojn de pagsistemoj, aŭ redirekti uzantdatenojn al CRM por akceli la prilaboradon de petoj de eblaj klientoj
Se vi havas grandan aplikaĵon kaj iuj partoj de la aplikaĵo povas esti efektivigitaj pli optimume uzante malsaman lingvon de la ĉefa. Ekzemple, vi havas projekton en Java kaj vi devas aldoni novajn funkciojn, sed vi ne havas liberajn manojn, aŭ efektivigo en difinita lingvo povas daŭri pli longe kaj jam ekzistas solvo en alia lingvo, tiam Serverless povas helpi ankaŭ kun ĉi tio.
Ĉi tio ne estas la tuta listo de iloj kaj teknologioj, kiuj meritas atenton; mi ĵus konigis tion, kion ni mem uzas ĉiutage en nia laboro kaj scias precize kiel ili povas helpi komercon.
fonto: www.habr.com