Innledning
Digital transformasjon dekker flere og flere ulike områder av livet og virksomheten hvert år. Hvis en virksomhet ønsker å være konkurransedyktig, er vanlige informasjonssider ikke lenger nok, det trengs mobil- og nettapplikasjoner som ikke bare gir brukerne informasjon, men som også lar dem utføre visse funksjoner: motta eller bestille varer og tjenester, levere verktøy.
For eksempel er det ikke lenger nok for moderne banker å ha en nettside med informasjon, de må ha nettbaserte verktøy for sine kunder, en personlig konto hvor brukeren kan administrere kontoer, investeringer og lån. Selv små bedrifter trenger praktiske verktøy for å øke konverteringer, for eksempel å avtale en avtale med en lege eller frisør, eller bestille bord på en restaurant eller et lekerom for barn til en bursdagsfest.
Og eierne selv trenger å motta rettidig informasjon i en praktisk form om tilstanden til selskapet deres, for eksempel innsamling av statistiske data og analyser for forskjellige produksjonsavdelinger, eller produktiviteten til avdelinger. Ofte samler hver avdeling inn disse dataene på sin egen måte, og kan til og med bruke forskjellige verktøy og eieren trenger å bruke mye personlig tid på å forstå alt dette, indirekte eller direkte dette kan påvirke selskapets effektivitet og til syvende og sist profitt. Digital transformasjon og utvikling av nett- eller mobilapplikasjoner vil også hjelpe her.
Teknologier står ikke stille og er i stadig utvikling, og det som ble brukt for flere år siden er kanskje ikke lenger aktuelt i dag, eller det som ikke kunne gjøres for flere år siden har allerede blitt en realitet. Det finnes mer moderne verktøy som hjelper deg med å lage nett- og mobilapplikasjoner raskere og bedre. Basert på personlige observasjoner og erfaringer ønsker jeg å dele min visjon om hvilke teknologier og verktøy som vil være etterspurt i nær fremtid og hvorfor du bør ta hensyn til dem når du lager en moderne nettapplikasjon.
Enkeltsideapplikasjon
La oss definere terminologien litt. Single Page Application (SPA) er en nettapplikasjon hvis komponenter lastes én gang på én side, og innholdet lastes inn etter behov. Og når du flytter mellom deler av applikasjonen, lastes ikke siden helt inn på nytt, men bare laster og viser de nødvendige dataene.
Enkeltsideapplikasjoner drar stor nytte av klassiske nettapplikasjoner når det gjelder hastighet og brukervennlighet. Ved hjelp av SPA kan du oppnå effekten av at et nettsted fungerer som en applikasjon på et skrivebord, uten omstart og betydelige forsinkelser.
Hvis enkeltsideapplikasjoner for noen år siden praktisk talt ikke støttet søkemotoroptimalisering og hovedsakelig ble brukt til å lage personlige kontoer og administrasjonspaneler, har det i dag blitt mye enklere å lage en enkeltsidesapplikasjon med full støtte for søkemotoroptimalisering (SEO). Ved å bruke servergjengitte enkeltsideapplikasjoner i dag, har dette problemet helt forsvunnet. Med andre ord, dette er den samme enkeltsideapplikasjonen, men på den første forespørselen genererer serveren ikke bare data, men lager en HTML-side klar for visning og søkemotorer mottar ferdige sider med all metainformasjon og semantisk markering .
Med utviklingen av verktøy for å lage nettapplikasjoner på klientsiden, vil utviklingen og overgangen til enkeltsideapplikasjoner bare vokse i dette og påfølgende år. Hvis du har en gammel applikasjon som er utdatert og fungerer sakte, og selv med en fullstendig sideinnlasting når du bytter mellom seksjoner, så kan du i år trygt oppgradere til en rask én-sides applikasjon - nå er det en god tid, teknologien lar deg allerede å gjøre dette ganske raskt og effektivt.
Å ha en moderne og rask nettside er veldig bra, men la meg si deg ærlig: Ikke alle applikasjoner kan enkelt konverteres til applikasjoner på én side, og overgangen kan bli dyr! Derfor må du forstå hvem som trenger en slik overgang og hvorfor.
For å hjelpe deg å forstå, vil jeg i tabellen nedenfor gi noen eksempler på når det er hensiktsmessig og berettiget å utvikle eller bytte til et SPA, og når det ikke er det.
ЗА
Hvis du ønsker å lage en moderne, rask applikasjon og vil bruke ikke bare webversjonen, men også mobil- eller til og med desktop-versjonen, og alle prosesser og beregninger foregår på en ekstern eller skyserver. Dessuten, slik at alle klienter har ett interaksjonsgrensesnitt og det er ikke nødvendig å gjøre hver redigering av serverkoden når du legger til en ny klient.
For eksempel: sosialt nettverk, aggregatorer, SaaS-plattformer (programvare som skytjeneste), markedsplasser
Hvis du har en butikk eller netttjeneste, vet du at det går sakte og folk drar, du vil gjøre det raskere, du forstår verdien av kundene og er klar til å betale over en million rubler for en oppgradering.
Du har en mobilapplikasjon som bruker nettstedets API, men siden er treg og har fullstendig innhold som lastes inn på nytt når du flytter mellom sider
IMOT
Hvis målgruppen din ikke bruker moderne nettlesere og enheter.
For eksempel: spesifikke bedriftsområder, som utvikling av interne systemer for banker, medisinske institusjoner og utdanning.
Du utfører hovedaktivitetene dine offline og er ikke klar til å tilby noen tjenester online, og du trenger bare å tiltrekke deg kunder.
Hvis du har en nettbutikk eller netttjeneste som allerede selger godt, ser du ikke kundestrøm eller klager
Hvis du har en fungerende applikasjon som ikke kan tilpasses SPA og du bare trenger å skrive om alt fra bunnen av og bruke andre teknologier, og du er ikke klar til å bruke flere millioner på dette.
For eksempel: Det er et innrammet nettsted eller en slags hjemmeskrevet gammel, monolittisk kode.
Progressive webapplikasjoner
Progressive webapplikasjoner er et produkt av den felles utviklingen av en innebygd applikasjon og en nettside. I hovedsak er dette en nettapplikasjon som ser ut og oppfører seg som en ekte innfødt applikasjon, kan motta push-varsler, jobbe i frakoblet modus, etc. I dette tilfellet trenger ikke brukeren å laste ned applikasjonen fra AppStore eller Google Play, men bare lagre den på skrivebordet.
Som en teknologi eller tilnærming til utvikling har PWA vært i utvikling siden 2015, og har nylig vunnet enorm popularitet innen e-handelsfeltet.
Noen eksempler fra det virkelige liv:
- i fjor var Best Western River North-hotellet i stand til å øke inntektene med 300 % etter å ha lansert et nytt PWA-aktivert nettsted;
- Arabisk Avito OpenSooq.com, etter å ha opprettet PWA-støtte på sin nettside, var i stand til å øke besøkstiden med 25 % og antall potensielle kunder med 260 %;
- den kjente datingtjenesten Tinder var i stand til å redusere lastehastigheten fra 11.91s til 4.69s ved å utvikle en PWA; dessuten veier applikasjonen 90% mindre enn sin opprinnelige Android-motpart.
Det faktum at det er verdt å ta hensyn til denne teknologien indikeres også av det faktum at en av de største motorene for å lage e-handelsprosjekter, Magento, lanserte en tidlig utviklingsversjon av PWA Studio i 2018. Plattformen lar deg lage en React-basert frontend ut av esken for dine e-handelsløsninger med PWA-støtte.
Råd for de som allerede har et Internett-prosjekt eller bare en idé om en ny tjeneste med støtte for mobile enheter: ikke skynd deg å skrive en fullverdig native applikasjon, men først se på PWA-teknologi. Dette kan være den beste løsningen for pengene for ditt produkt.
Litt fra praksis. For å lage en enkel innfødt mobilnyhetsapplikasjon, forutsatt at du allerede har en ferdig REST-server, trenger du omtrent 200-300 dugnadstimer per plattform. Med den gjennomsnittlige markedsprisen for en time med utvikling på 1500-2000 rubler/time, kan en applikasjon koste omtrent 1 million rubler. Utvikler du en nettapplikasjon med full støtte for PWA: push-varslinger, offline-modus og andre godbiter, så vil utviklingen ta 200-300 arbeidstimer, men produktet vil umiddelbart være tilgjengelig på alle plattformer. Det vil si en besparelse på ca. 2 ganger, for ikke å nevne det faktum at du slipper å betale gebyrer for plassering i applikasjonsbutikker.
server~~POS=TRUNC
Dette er en annen moderne tilnærming til utvikling. På grunn av navnet tror mange at dette er virkelig serverløs utvikling, det er ikke nødvendig å skrive back-end-kode, og enhver front-end-utvikler kan lage en fullverdig webapplikasjon. Men det er ikke sant!
Når du oppretter en serverløs applikasjon, trenger du fortsatt en server og en database. Hovedforskjellen med denne tilnærmingen er at back-end-koden presenteres i form av skyfunksjoner (et annet navn for serverløs er FaaS, fungerer som en tjeneste eller Functions-as-a-Service) og lar applikasjonen skalere raskt og Enkelt. Når du oppretter en slik applikasjon, kan utvikleren fokusere på forretningsproblemer og ikke tenke på å skalere og sette opp infrastrukturen, noe som i ettertid øker applikasjonsutviklingen og reduserer kostnadene. Dessuten vil serverløs-tilnærmingen hjelpe deg med å spare på serverleie, siden den bruker nøyaktig så mange ressurser som er nødvendig for å fullføre oppgaven, og hvis det ikke er noen belastning, blir ikke servertiden brukt i det hele tatt og det blir ikke betalt for.
For eksempel klarte det store amerikanske medieselskapet Bustle å redusere hostingkostnadene med mer enn 60 % ved bytte til Serverless. Og Coca-Cola-selskapet, da de utviklet et automatisert system for salg av drinker gjennom salgsautomater, klarte å redusere hostingkostnadene fra $13000 4500 til $XNUMX per år ved å bytte til Serverless.
I løpet av de siste par årene, på grunn av nyheten og dens begrensninger, har Serverless hovedsakelig blitt brukt til små prosjekter, oppstart og MVP-er, men i dag, takket være utviklingen av programvare, allsidigheten og kraften til servercontainerisering, dukker det opp verktøy som lar deg fjerne restriksjoner, forenkle og fremskynde utviklingen av skyapplikasjoner.
Dette betyr at bedriftsscenarier der skymodernisering tidligere ble ansett som umulig (for eksempel for edge-enheter, data under transport eller stateful-applikasjoner) nå er en realitet. Gode verktøy som viser mye lovende er kNative og Serverless enterprise.
Men til tross for alt dette, er ikke Serverless en sølvkule for utvikling av webapplikasjoner. Som all annen teknologi har den sine fordeler og ulemper, og du må velge dette verktøyet med forståelse, og "ikke slå spiker med et mikroskop" bare fordi det er mer teknologisk avansert.
For å hjelpe deg med å finne ut av det, her er noen eksempler på når du kanskje vil vurdere serverløs når du utvikler en ny eller forbedrer en nåværende nettjeneste:
- Når belastningen på serveren er periodisk og du betaler for ledig kapasitet. For eksempel hadde vi en klient med et nettverk av kaffemaskiner og det var nødvendig å behandle forespørsler og samle inn statistikk bare noen hundre eller tusen ganger om dagen, og om natten falt antallet forespørsler til flere dusin. I dette tilfellet er det mye mer effektivt å betale kun for den faktiske ressursbruken, så vi foreslo og implementerte en løsning på Serverless;
- Hvis du ikke planlegger å dykke ned i de tekniske detaljene i infrastrukturen og betale for mye for å sette opp og vedlikeholde servere og en balanserer. For eksempel, når du utvikler en markedsplass, vet du ikke nøyaktig hva trafikken vil være, eller omvendt - du planlegger mye trafikk og slik at applikasjonen din er sikker på å tåle belastningen, er Serverless et utmerket valg.
- Hvis du trenger å utføre noen strømmehendelser i hovedapplikasjonen, skriv sidedata inn i tabeller, utfør noen beregninger. For eksempel samle analytiske data om brukerhandlinger, behandle dem på en bestemt måte og lagre dem i en database;
- Hvis du trenger å forenkle, forene eller øke hastigheten på den nåværende driften av applikasjonen. Lag for eksempel ytelsesforbedrende tjenester for arbeid med bilder eller videoer, når brukeren laster opp video til skyen, og en egen funksjon håndterer transkoding, mens hovedserveren fortsetter å fungere som normalt.
Hvis du trenger å behandle hendelser fra tredjepartstjenester. For eksempel behandle svar fra betalingssystemer, eller omdirigere brukerdata til CRM for å fremskynde behandlingen av forespørsler fra potensielle kunder
Hvis du har en stor applikasjon og noen deler av applikasjonen kan implementeres mer optimalt ved å bruke et annet språk enn hovedspråket. For eksempel har du et prosjekt i Java og du må legge til ny funksjonalitet, men du har ikke noen ledige hender, eller implementering på et gitt språk kan ta lengre tid og det allerede finnes en løsning på et annet språk, da kan Serverless hjelpe med dette også.
Dette er ikke hele listen over verktøy og teknologier som fortjener oppmerksomhet; Jeg har bare delt hva vi selv bruker hver dag i arbeidet vårt og vet nøyaktig hvordan de kan hjelpe virksomheten.
Kilde: www.habr.com