Inleiding
Digitale transformasie dek elke jaar meer en meer verskillende areas van die lewe en besigheid. As 'n onderneming mededingend wil wees, is gewone inligtingswebwerwe nie meer genoeg nie, mobiele en webtoepassings word benodig wat nie net aan gebruikers inligting verskaf nie, maar hulle ook toelaat om sekere funksies te verrig: goedere en dienste te ontvang of te bestel, gereedskap te verskaf.
Dit is byvoorbeeld nie meer genoeg vir moderne banke om 'n webwerf met inligting te hê nie; hulle moet aanlynhulpmiddels vir hul kliënte hê, 'n persoonlike rekening waar die gebruiker rekeninge, beleggings en lenings kan bestuur. Selfs klein besighede het gerieflike gereedskap nodig om omskakelings te verhoog, soos om 'n afspraak met 'n dokter of haarkapper te maak, of 'n tafel by 'n restaurant of 'n kinderspeelkamer vir 'n verjaardagpartytjie te bespreek.
En die eienaars self moet tydige inligting in 'n gerieflike vorm ontvang oor die stand van hul maatskappy, byvoorbeeld die versameling van statistiese data en analise vir verskillende produksiedepartemente, of die produktiwiteit van departemente. Dikwels versamel elke departement hierdie data op sy eie manier, en kan selfs verskillende instrumente gebruik en die eienaar moet baie persoonlike tyd spandeer om dit alles te verstaan, indirek of direk kan dit die maatskappy se doeltreffendheid en uiteindelik wins beïnvloed. Digitale transformasie en web- of mobiele toepassingsontwikkeling sal ook hier help.
Tegnologieë staan nie stil nie en ontwikkel voortdurend, en wat etlike jare gelede gebruik is, is dalk vandag nie meer relevant nie, of wat etlike jare gelede nie gedoen kon word nie, het reeds 'n werklikheid geword. Daar is meer moderne gereedskap wat jou help om web- en mobiele toepassings vinniger en beter te skep. Op grond van persoonlike waarnemings en ervaring wil ek my visie deel van watter tegnologieë en gereedskap in die nabye toekoms in aanvraag sal wees en waarom jy daaraan moet aandag gee wanneer jy 'n moderne webtoepassing skep.
Enkelbladsy-toepassing
Kom ons definieer die terminologie 'n bietjie. Single Page Application (SPA) is 'n webtoepassing waarvan die komponente een keer op een bladsy gelaai word, en die inhoud word gelaai soos nodig. En wanneer tussen afdelings van die toepassing beweeg word, herlaai die bladsy nie heeltemal nie, maar laai en vertoon slegs die nodige data.
Enkelbladsy-toepassings baat grootliks by klassieke webtoepassings in terme van spoed en gebruiksgemak. Met die hulp van SPA kan u die effek verkry van 'n webwerf wat soos 'n toepassing op 'n rekenaar werk, sonder herlaai en aansienlike vertragings.
As 'n paar jaar gelede enkelbladsytoepassings feitlik nie soekenjinoptimalisering ondersteun het nie en hoofsaaklik vir die skep van persoonlike rekeninge en administrasiepanele gebruik is, het dit vandag baie makliker geword om 'n enkelbladsytoepassing met volle ondersteuning vir soekenjinoptimalisering (SEO) te skep. Met behulp van bediener-weergegee enkelbladsy-toepassings vandag, het hierdie probleem heeltemal verdwyn. Met ander woorde, dit is dieselfde enkelbladsy-toepassing, maar op die eerste versoek genereer die bediener nie net data nie, maar skep 'n HTML-bladsy wat gereed is vir vertoon en soekenjins ontvang klaargemaakte bladsye met al die meta-inligting en semantiese opmaak .
Met die ontwikkeling van gereedskap vir die skep van kliënt-kant webtoepassings, sal die ontwikkeling en oorgang na enkelbladsytoepassings eers in hierdie en daaropvolgende jare groei. As jy 'n ou toepassing het wat verouderd is en stadig werk, en selfs met 'n volledige bladsy herlaai wanneer jy tussen afdelings wissel, dan kan jy vanjaar veilig opgradeer na 'n vinnige eenbladsy-toepassing - dit is nou 'n goeie tyd, tegnologie laat jou reeds toe om dit redelik vinnig en doeltreffend te doen.
Om 'n moderne en vinnige webwerf te hê is baie goed, maar laat ek jou eerlik sê: nie alle toepassings kan maklik na enkelbladsytoepassings omgeskakel word nie, en die oorgang kan duur wees! Daarom moet jy verstaan wie so 'n oorgang nodig het en hoekom.
Om jou te help verstaan, sal ek in die tabel hieronder 'n paar voorbeelde gee van wanneer ontwikkeling of oorskakeling na 'n SPA gepas en geregverdig is, en wanneer dit nie is nie.
VIR
As jy 'n moderne, vinnige toepassing wil maak en nie net die webweergawe wil gebruik nie, maar ook die mobiele of selfs rekenaarweergawe, en alle prosesse en berekeninge vind op 'n afgeleë of wolkbediener plaas. Verder, sodat alle kliënte een interaksie-koppelvlak het en dit nie nodig is om elke wysiging aan die bedienerkode te maak wanneer 'n nuwe kliënt bygevoeg word nie.
Byvoorbeeld: sosiale netwerk, aggregators, SaaS-platforms (sagteware as 'n wolkdiens), markplekke
As jy 'n winkel of webdiens het, weet jy dat dit stadig is en mense vertrek, jy wil dit vinniger maak, jy verstaan die waarde van kliënte en is gereed om meer as 'n miljoen roebels te betaal vir 'n opgradering.
Jy het 'n mobiele toepassing wat die werf se API gebruik, maar die werf is stadig en het volledige inhoud herlaai wanneer jy tussen bladsye beweeg
TEGEN
As jou teikengehoor nie moderne blaaiers en toestelle gebruik nie.
Byvoorbeeld: spesifieke korporatiewe gebiede, soos die ontwikkeling van interne stelsels vir banke, mediese instellings en onderwys.
Jy voer jou hoofaktiwiteite vanlyn uit en is nie gereed om enige dienste aanlyn te verskaf nie, en jy hoef net klante te lok.
As jy 'n aanlynwinkel of webdiens het wat reeds goed verkoop, sien jy nie klante-uitvloei of klagtes nie
As jy 'n werkende toepassing het wat nie vir SPA aangepas kan word nie en jy hoef net alles van nuuts af te herskryf en ander tegnologieë te gebruik, en jy is nie gereed om 'n paar miljoen hieraan te spandeer nie.
Byvoorbeeld: Daar is 'n bokswerf of 'n soort tuisgeskrewe antieke, monolitiese kode.
Progressiewe webtoepassings
Progressiewe webtoepassings is die produk van die gesamentlike evolusie van 'n inheemse toepassing en 'n webwerf. In wese is dit 'n webtoepassing wat soos 'n regte inheemse toepassing lyk en optree, stootkennisgewings kan ontvang, in die aflynmodus kan werk, ens. In hierdie geval hoef die gebruiker nie die toepassing van die AppStore of Google Play af te laai nie, maar dit bloot op die lessenaar te stoor.
As 'n tegnologie of benadering tot ontwikkeling, ontwikkel PWA sedert 2015, en het onlangs enorme gewildheid in die e-handelsveld verwerf.
Enkele werklike voorbeelde:
- verlede jaar kon die Best Western River North-hotel inkomste met 300% verhoog ná die bekendstelling van 'n nuwe PWA-geaktiveerde webwerf;
- Arabies Avito OpenSooq.com, nadat hy PWA-ondersteuning op sy webwerf geskep het, kon die tyd van besoek aan die webwerf met 25% en die aantal leidrade met 260% verhoog;
- die bekende afspraakdiens Tinder kon die laaispoed van 11.91s tot 4.69s verminder deur 'n PWA te ontwikkel; bowendien weeg die toepassing 90% minder as sy inheemse Android-eweknie.
Die feit dat dit die moeite werd is om aandag aan hierdie tegnologie te gee, word ook aangedui deur die feit dat een van die grootste enjins vir die skep van e-handelsprojekte, Magento, 'n vroeë ontwikkelingsweergawe van PWA Studio in 2018 bekendgestel het. Die platform laat jou toe om 'n React-gebaseerde frontend uit die boks te skep vir jou e-handelsoplossings met PWA-ondersteuning.
Raad vir diegene wat reeds 'n internetprojek het of net 'n idee vir 'n nuwe diens met ondersteuning vir mobiele toestelle het: moenie haastig wees om 'n volwaardige inheemse toepassing te skryf nie, maar kyk eers na PWA-tegnologie. Dit is dalk die beste waarde-vir-geld-oplossing vir jou produk.
Bietjie uit die praktyk. Om 'n eenvoudige inheemse mobiele nuustoepassing te skep, mits jy reeds 'n klaargemaakte REST-bediener het, benodig jy ongeveer 200-300 man-ure per platform. Met die gemiddelde markprys vir 'n uur van ontwikkeling wat 1500-2000 roebels / uur is, kan 'n toepassing ongeveer 1 miljoen roebels kos. As jy 'n webtoepassing ontwikkel met volle ondersteuning vir PWA: stootkennisgewings, vanlynmodus en ander goedjies, dan sal die ontwikkeling 200-300 man-ure neem, maar die produk sal onmiddellik op alle platforms beskikbaar wees. Dit wil sê 'n besparing van ongeveer 2 keer, om nie eens te praat van die feit dat jy nie fooie hoef te betaal vir plasing in toepassingswinkels nie.
serverless
Dit is nog 'n moderne benadering tot ontwikkeling. As gevolg van die naam, dink baie mense dat dit werklik bedienerlose ontwikkeling is, dit is nie nodig om back-end-kode te skryf nie, en enige front-end-ontwikkelaar kan 'n volwaardige webtoepassing skep. Maar dis nie waar nie!
Wanneer u 'n bedienerlose toepassing skep, benodig u steeds 'n bediener en 'n databasis. Die belangrikste verskil van hierdie benadering is dat die back-end-kode in die vorm van wolkfunksies aangebied word ('n ander naam vir bedienerloos is FaaS, funksioneer as 'n diens of Functions-as-a-Service) en laat die toepassing toe om vinnig te skaal en maklik. Wanneer so 'n toepassing geskep word, kan die ontwikkelaar op besigheidsprobleme fokus en nie daaraan dink om die infrastruktuur te skaal en op te stel nie, wat daarna toepassingsontwikkeling versnel en die koste daarvan verminder. Boonop sal die bedienerlose benadering u help om op bedienerhuur te bespaar, aangesien dit presies soveel hulpbronne gebruik as wat nodig is om die taak te voltooi, en as daar geen vrag is nie, word bedienertyd glad nie gebruik nie en word nie daarvoor betaal nie.
Die groot Amerikaanse mediamaatskappy Bustle kon byvoorbeeld gasheerkoste met meer as 60% verminder toe daar na Serverless oorgeskakel is. En die Coca-Cola-maatskappy, toe die ontwikkeling van 'n outomatiese stelsel vir die verkoop van drankies deur vendingmasjiene, was in staat om gasheerkoste van $13000 tot $4500 per jaar te verminder deur oor te skakel na Serverless.
Oor die afgelope paar jaar, as gevolg van sy nuutheid en sy beperkings, is Serverless hoofsaaklik gebruik vir klein projekte, beginondernemings en MVP's, maar vandag, danksy die evolusie van sagteware, die veelsydigheid en krag van bedienerhouerisering, kom nutsmiddels na vore wat laat jou toe om beperkings te verwyder, die ontwikkeling van wolktoepassings te vereenvoudig en te bespoedig.
Dit beteken dat ondernemingsake-scenario's waar wolkmodernisering voorheen as onmoontlik beskou is (byvoorbeeld vir randtoestelle, data in transito of statige toepassings) nou 'n werklikheid is. Goeie instrumente wat baie belofte toon, is kNative en Serverless enterprise.
Maar ten spyte van dit alles, is Serverless nie 'n silwer koeël vir die ontwikkeling van webtoepassings nie. Soos enige ander tegnologie, het dit sy voordele en nadele, en jy moet hierdie instrument met begrip kies, en "nie spykers met 'n mikroskoop hamer nie" net omdat dit meer tegnologies gevorderd is.
Om jou te help om dit uit te vind, is hier 'n paar voorbeelde van wanneer jy dalk bedienerloos wil oorweeg wanneer jy 'n nuwe of 'n huidige webdiens ontwikkel:
- Wanneer die las op die bediener periodiek is en jy betaal vir ledige kapasiteit. Ons het byvoorbeeld 'n kliënt gehad met 'n netwerk van koffiemasjiene en dit was nodig om versoeke te verwerk en statistieke net 'n paar honderd of duisend keer per dag in te samel, en snags het die aantal versoeke tot 'n paar dosyn gedaal. In hierdie geval is dit baie meer doeltreffend om slegs vir die werklike gebruik van hulpbronne te betaal, daarom het ons 'n oplossing op Serverless voorgestel en geïmplementeer;
- As jy nie van plan is om in die tegniese besonderhede van die infrastruktuur te duik en te veel te betaal vir die opstel en instandhouding van bedieners en 'n balanseerder nie. Byvoorbeeld, wanneer jy 'n mark ontwikkel, weet jy nie presies wat die verkeer sal wees nie, of andersom - jy beplan baie verkeer en sodat jou toepassing sekerlik die las sal weerstaan, dan is Serverless 'n uitstekende keuse.
- As jy 'n paar stroomgebeurtenisse in die hooftoepassing moet uitvoer, skryf sydata in tabelle, voer 'n paar berekeninge uit. Versamel byvoorbeeld analitiese data van gebruikersaksies, verwerk dit op 'n sekere manier en stoor dit in 'n databasis;
- As u die huidige werking van die toepassing moet vereenvoudig, verenig of versnel. Skep byvoorbeeld prestasieverbeterende dienste om met beelde of video's te werk, wanneer die gebruiker video na die wolk oplaai, en 'n aparte funksie hanteer transkodering, terwyl die hoofbediener voortgaan om soos normaal te werk.
As jy gebeure van derdeparty-dienste moet verwerk. Verwerk byvoorbeeld antwoorde vanaf betalingstelsels, of herlei gebruikersdata na CRM om die verwerking van versoeke van potensiële kliënte te bespoedig
As jy 'n groot toepassing het en sommige dele van die toepassing kan meer optimaal geïmplementeer word deur 'n ander taal as die hoof een te gebruik. Byvoorbeeld, jy het 'n projek in Java en jy moet nuwe funksionaliteit byvoeg, maar jy het geen vrye hande nie, of implementering in 'n gegewe taal kan langer neem en daar is reeds 'n oplossing in 'n ander taal, dan kan Serverless help hiermee ook.
Dit is nie die hele lys gereedskap en tegnologieë wat aandag verdien nie; Ek het net gedeel wat ons self elke dag in ons werk gebruik en weet presies hoe dit besigheid kan help.
Bron: will.com