Introduktion
Den digitale transformation dækker hvert år flere og flere forskellige aspekter af livet og forretningen. Hvis en virksomhed vil være konkurrencedygtig, er almindelige informationswebsteder ikke længere tilstrækkelige; der er brug for mobil- og webapplikationer, som ikke blot giver brugerne information, men også muliggør udførelse af forskellige funktioner: modtage eller bestille varer og tjenester, samt tilbyde værktøjer.
For eksempel er det ikke længere tilstrækkeligt for moderne banker at have en hjemmeside med information; de skal have online værktøjer til deres kunder, en personlig konto, hvor brugeren kan administrere konti, investeringer og lån. Selv små virksomheder har brug for brugervenlige værktøjer for at øge konverteringen, såsom at booke tid til en læge eller frisør, eller reservere et bord i en restaurant eller et legeområde til en fødselsdag.
Og selve ejerne skal rettidigt modtage information i en bekvem form om tilstanden for deres virksomhed, for eksempel indsamling af statistiske data og analyse fra forskellige produktionsafdelinger, eller afdelingers produktivitet. Ofte indsamler hver afdeling disse data på sin egen måde, og de kan endda bruge forskellige værktøjer, hvilket kræver, at ejerne bruger meget personlig tid på at forstå al dette; dette kan indirekte eller direkte påvirke virksomhedens effektivitet og i sidste ende fortjenesten. Også her kan den digitale transformation samt udviklingen af en web- eller mobilapplikation være til hjælp.
Teknologierne står ikke stille og udvikler sig konstant, og det, der blev brugt for flere år siden, kan allerede være forældet i dag, eller det, man ikke kunne gøre for flere år siden, er nu blevet en realitet. Der findes nu et større antal moderne værktøjer, der hjælper med at skabe web- og mobilapplikationer hurtigere og bedre. Baseret på mine personlige observationer og erfaringer ønsker jeg at dele min vision om, hvilke teknologier og værktøjer der vil være eftertragtede i den nærmeste fremtid, og hvorfor det er værd at holde øje med dem, når man skaber en moderne webapplikation.
Single page application (enkelsideapplikationer)
Lad os definere nogle termer. En Single Page Application (SPA) er en webapplikation, hvis komponenter indlæses én gang på én side, mens indholdet hentes efter behov. Når man navigerer mellem sektioner i applikationen, genindlæses siden ikke helt, men de nødvendige data indlæses og vises blot.
Enkelsided-applikationer har markante fordele i hastighed og brugervenlighed sammenlignet med klassiske webapplikationer. Med en SPA kan man opnå effekten af at arbejde med et websted som et desktop-applikation, uden genindlæsninger og væsentlige forsinkelser.
For nogle år siden understøttede enkle applikationer praktisk talt ikke søgemaskineoptimering, og de blev primært brugt til at skabe brugerprofiler og administrationspaneler. I dag er det blevet meget enklere at skabe en SP-app med fuld støtte til søgemaskineoptimering (SEO). Ved at bruge en SP-app med server-side rendering er dette problem helt løst. Med andre ord, det er stadig en SPA, men ved den første anmodning genererer serveren ikke blot data, men opretter en HTML-side klar til visning, og søgemaskinerne får færdige sider med al metadata og semantisk markup.
Med udviklingen af værktøjer til oprettelse af klientbaserede webapplikationer vil udviklingen og overgangen til SPA'er i dette og de kommende år kun stige. Hvis du har en gammel applikation, der er moralsk forældet og arbejder langsomt, og som genindlæser siden fuldstændigt, når du skifter mellem sektioner, kan du i år trygt opgradere til en hurtig SPA – det er et godt tidspunkt, og teknologierne tillader det nu ret hurtigt og effektivt.
At have en moderne og hurtig webside er rigtig godt, men jeg vil ærligt sige: ikke alle applikationer kan nemt omlægges til en SPA, og overgangen kan være dyr! Derfor er det vigtigt at forstå, hvem og hvorfor en sådan overgang er nødvendig.
For at hjælpe dig med at forstå, vil jeg i tabellen nedenfor give nogle eksempler på, hvornår det er passende og berettiget at udvikle eller overgå til en SPA, og hvornår det ikke er.
ZA
Hvis du vil lave en moderne, hurtig applikation, og ønsker at den ikke kun skal være tilgængelig i webversionen, men også som mobil- eller endda desktopversion, hvor alle processer og beregninger sker på en ekstern eller cloudserver. Og så samtidig sikre, at alle kunder har et ensartet brugergrænseflade, uden at det er nødvendigt at ændre serverkoden for hver ny kunde.
For eksempel: sociale netværk, aggregatorer, SaaS-platforme (software som en tjeneste), markedspladser.
Hvis du har en butik eller en webtjeneste, ved du, at den er langsom, og folk forlader den. Du ønsker at gøre den hurtigere, forstår værdien af kunderne og er villig til at betale for en opgradering fra en million kroner.
Du har en mobilapp, der bruger API fra dit website, og hjemmesiden er langsom med fulde genindlæsninger af indholdet, når der skiftes mellem sider.
IMOD
Hvis din målgruppe ikke bruger moderne browsere og enheder.
For eksempel: specifikke virksomhedsområder, såsom udvikling af interne systemer til banker, sundhedsvæsen og uddannelse.
Hvis din primære aktivitet foregår offline, og du ikke er klar til at tilbyde nogen tjenester online, og du blot har brug for at tiltrække kunder.
Hvis du har en online butik eller en webtjeneste, som allerede sælger godt, ser du ikke noget kundeafgang eller klager.
Hvis du har en fungerende applikation, der ikke kan tilpasses til SPA og hvor det hele skal omskrives fra bunden med andre teknologier, og du ikke er klar til at bruge flere millioner på det.
For eksempel: der er en boxet hjemmeside eller noget selvskrevet gammelt, monolitisk kode.
Progressive Web Applications
Progressive Web Applications (progressiv webapplikation) er et produkt af den fælles evolution af nativ applikation og hjemmeside. I sin essens er det en webapplikation, der ser ud og opfører sig som en ægte, nativ applikation, kan modtage push-notifikationer, fungere i offline-tilstand osv. Brugeren skal ikke downloade appen fra App Store eller Google Play, men blot gemme den på skrivebordet.
Som teknologi eller tilgang til udvikling har PWA udviklet sig siden 2015, og i den seneste tid har den vundet enorm popularitet inden for e-handelsområdet.
Nogle reelle eksempler fra livet:
- Sidste år kunne hotellet Best Western River North, efter lanceringen af deres nye PWA-understøttede hjemmeside, øge indtægterne med 300%;
- Den arabiske Avito OpenSooq.com kunne efter at have implementeret PWA-understøttelse på deres hjemmeside øge besøgestiden med 25% og antallet af leads med 260%;
- Den velkendte datingtjeneste Tinder formåede at reducere indlæsningstiden fra 11,91 sekunder til 4,69 sekunder ved at udvikle PWA, desuden fylder appen 90% mindre end sin native Android-ækvivalent.
At fokusere på denne teknologi understreges også af, at en af de største platforme til e-handelsprojekter, Magento, i 2018 lancerede en tidlig udviklerversion af PWA Studio. Plattformen gør det muligt at 'out-of-the-box' skabe frontend baseret på React til deres e-handelsløsninger med PWA-understøttelse.
Et råd til dem, der allerede har et internetprojekt eller blot idéen til en ny service med mobilunderstøttelse: Skynd jer ikke med at skrive en fuld nativ app, men se først på PWA-teknologien. Det kan muligvis være den bedste løsning med hensyn til pris og kvalitet for dit produkt.
Lidt fra praksis. For at skabe en simpel nativ mobil nyhedsapp, forudsat at der allerede er en klar REST-server, kræves der cirka 200-300 mandetimer pr. platform. Med en gennemsnitlig markedspris på 1500-2000 rubler/timer kan appen koste omkring 1 million rubler. Hvis man udvikler en webapplikation med fuld PWA-understøttelse: push-notifikationer, offline-tilstand og andre fordele, vil udviklingen tage 200-300 mandetimer, men produktet vil straks være tilgængeligt på alle platforme. Det vil sige en besparelse på cirka 2 gange, for ikke at nævne, at man slipper for at betale gebyrer for offentliggørelse i app-butikkerne.
Serverless
Dette er en anden moderne tilgang til udvikling. På grund af navnet tror mange, at det virkelig er serverless udvikling, og at man ikke behøver at skrive back-end kode, og enhver frontend-udvikler kan lave en fuld webapplikation. Men det er ikke tilfældet!
Når man opretter en serverless-applikation, er en server stadig nødvendig, ligesom databaser. Den primære forskel ved denne tilgang er, at back-end koden præsenteres i form af cloud-funktioner (et andet navn for serverless er FaaS, funktioner som service) og giver applikationen mulighed for hurtigt og nemt at skaleres. Når man opretter en sådan applikation, kan udvikleren fokusere på forretningsopgaver og slippe for at tænke på skalerings- og infrastrukturindstillinger, hvilket efterfølgende fremskynder udviklingen af applikationen og reducerer omkostningerne. Desuden kan serverless-tilgangen hjælpe med at spare på lejen servere, da den bruger præcis så mange ressourcer, som der er behov for at udføre opgaven, og hvis der ikke er nogen belastning, så anvendes servertid slet ikke og betales ikke.
For eksempel har det store amerikanske medieselskab Bustle været i stand til at reducere omkostningerne med hosting mere end 60% ved at skifte til serverless. Og Coca-Cola, ved udviklingen af et automatiseret system til salg af drikkevarer gennem automater, har formået at reducere hostingomkostningerne fra $13.000 til $4.500 om året ved at skifte til serverless.
De sidste par år er serverless hovedsageligt blevet brugt til små projekter, startups og MVP'er på grund af nyheden og sine begrænsninger, men i dag, takket være softwareudviklingen, alsidigheden og styrken ved containerisering af servere, dukker der værktøjer op, der muliggør fjernelse af begrænsninger og forenkling samt accelerering af udviklingen af cloud-applikationer.
Det betyder, at virksomhedsscenarier, hvor cloud-moderisering tidligere blev anset for umulig (f.eks. for perifere enheder, dataoverførsel eller tilstandbevarende applikationer), nu er blevet en realitet. Gode værktøjer, der giver håb, er kNative og serverless enterprise.
Men på trods af alt dette er serverless ikke en sølvkugle for udvikling af webapplikationer. Som enhver anden teknologi har den sine fordele og ulemper, og det er vigtigt at vælge dette værktøj med omtanke, og "ikke slå søm i med et mikroskop" blot fordi det er mere teknologisk avanceret.
For at hjælpe dig med at forstå, her er nogle eksempler, på hvornår det kan være værd at overveje serverless ved udviklingen af en ny eller forbedringen af en nuværende webservice:
- Når serverbelastningen har en periodisk karakter, og du betaler for inaktiv kapacitet. For eksempel havde vi en kunde med et netværk af kaffemaskiner, der kun skulle håndtere anmodninger og indsamle statistik et par hundrede eller tusinde gange om dagen, mens antallet af anmodninger om natten faldt til kun få tiere. I dette tilfælde er det langt mere effektivt at betale kun for den faktiske brug af ressourcer, derfor foreslog og implementerede vi en løsning baseret på Serverless;
- Hvis du ikke planlægger at dykke ned i de tekniske detaljer omkring infrastrukturen og betale for opsætning og support af servere og load balancere. For eksempel, når du udvikler en markedsplads, ved du ikke, hvilken besøgsfrekvens den vil have, eller omvendt - planlægger du stor besøgsfrekvens, og du vil sikre, at din applikation kan håndtere belastningen, så er Serverless et fremragende valg.
- Hvis det er nødvendigt at udføre nogle strømende hændelser i hovedapplikationen, registrere sideløbende data i tabeller eller udføre beregninger. For eksempel indsamle analytiske data om brugerhandlinger, behandle dem på en bestemt måde og gemme dem i databasen;
- Hvis det er nødvendigt at forenkle, standardisere eller fremskynde det nuværende arbejde i applikationen. For eksempel at skabe ydeevneforbedrende tjenester til arbejde med billeder eller videoer, når en bruger uploader en video til skyen, og transkodning håndteres af en separat funktion, mens hovedserveren fortsætter med at fungere normalt.
Hvis du skal behandle begivenheder fra tredjeparts tjenester. For eksempel at behandle svar fra betalingssystemer eller omdirigere brugerdata til CRM for at fremskynde behandlingen af anmodninger fra potentielle kunder.
Hvis du har en stor applikation, hvor nogle dele kan implementeres mere optimalt med et sprog, der adskiller sig fra hovedsproget. For eksempel, hvis du har et projekt i Java og skal tilføje ny funktionalitet, men ikke har ledige hænder, eller implementeringen i dette sprog vil tage længere tid, og der allerede findes en løsning på et andet sprog, så kan Serverless også hjælpe med dette.
Dette er langt fra en udtømmende liste over værktøjer og teknologier, der fortjener opmærksomhed; jeg har bare delt det, vi selv bruger hver dag i vores arbejde, og vi ved bestemt, hvordan de kan hjælpe virksomheder.
Kilde: habr.com
