Indledning
Digital transformation dækker hvert år flere og flere forskellige områder af livet og erhvervslivet. Hvis en virksomhed ønsker at være konkurrencedygtig, er almindelige informationssider ikke længere nok, der er brug for mobil- og webapplikationer, der ikke kun giver brugerne information, men også giver dem mulighed for at udføre visse funktioner: modtage eller bestille varer og tjenester, levere værktøjer.
For eksempel er det ikke længere nok 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 praktiske værktøjer til at øge konverteringer, såsom at lave en aftale med en læge eller frisør eller bestille bord på en restaurant eller et legerum for børn til en fødselsdagsfest.
Og ejerne skal selv modtage rettidig information i en bekvem form om deres virksomheds tilstand, for eksempel indsamling af statistiske data og analyser for forskellige produktionsafdelinger eller afdelingernes produktivitet. Ofte indsamler hver afdeling disse data på sin egen måde, og kan endda bruge forskellige værktøjer, og ejeren skal bruge en masse personlig tid på at forstå alt dette, indirekte eller direkte, dette kan påvirke virksomhedens effektivitet og i sidste ende profit. Digital transformation og web- eller mobilapplikationsudvikling vil også hjælpe her.
Teknologier står ikke stille og er i konstant udvikling, og det, der blev brugt for flere år siden, er måske ikke længere relevant i dag, eller det, der ikke kunne lade sig gøre for flere år siden, er allerede blevet en realitet. Der er mere moderne værktøjer, der hjælper dig med at skabe web- og mobilapplikationer hurtigere og bedre. På baggrund af personlige observationer og erfaringer vil jeg dele min vision om, hvilke teknologier og værktøjer der vil blive efterspurgt i den nærmeste fremtid, og hvorfor du skal være opmærksom på dem, når du laver en moderne webapplikation.
Enkeltside applikation
Lad os definere terminologien lidt. Single Page Application (SPA) er en webapplikation, hvis komponenter indlæses én gang på én side, og indholdet indlæses efter behov. Og når du flytter mellem sektioner af applikationen, genindlæses siden ikke helt, men indlæser og viser kun de nødvendige data.
Enkeltsidede applikationer har stor gavn af klassiske webapplikationer med hensyn til hastighed og brugervenlighed. Ved hjælp af SPA kan du opnå effekten af, at en hjemmeside fungerer som en applikation på en desktop, uden genstart og væsentlige forsinkelser.
Hvis enkeltsidesapplikationer for et par år siden praktisk talt ikke understøttede søgemaskineoptimering og hovedsageligt blev brugt til at oprette personlige konti og administrationspaneler, er det i dag blevet meget lettere at oprette en enkeltsidesapplikation med fuld understøttelse af søgemaskineoptimering (SEO). Ved at bruge server-renderede enkeltsideapplikationer i dag er dette problem fuldstændigt forsvundet. Med andre ord er dette den samme enkeltsidede applikation, men på den første anmodning genererer serveren ikke bare data, men skaber en HTML-side klar til visning, og søgemaskiner modtager færdige sider med al metainformation og semantisk markup .
Med udviklingen af værktøjer til at skabe webapplikationer på klientsiden, vil udviklingen og overgangen til enkeltsidede applikationer kun vokse i dette og efterfølgende år. Hvis du har en gammel applikation, der er forældet og fungerer langsomt, og endda med en komplet sidegenindlæsning, når du skifter mellem sektioner, så kan du i år roligt opgradere til en hurtig en-sides applikation - nu er det et godt tidspunkt, teknologien giver dig allerede mulighed for at gøre dette ret hurtigt og effektivt.
At have en moderne og hurtig hjemmeside er meget godt, men lad mig sige dig ærligt: Ikke alle applikationer kan nemt konverteres til applikationer på én side, og overgangen kan være dyr! Derfor skal du forstå, hvem der har brug for sådan en overgang og hvorfor.
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 skifte til en SPA, og hvornår det ikke er det.
ЗА
Hvis du vil lave en moderne, hurtig applikation og vil bruge ikke kun webversionen, men også mobil- eller endda desktop-versionen, og alle processer og beregninger foregår på en fjern- eller cloud-server. Desuden, så alle klienter har én interaktionsgrænseflade, og der er ingen grund til at foretage enhver redigering af serverkoden, når der tilføjes en ny klient.
For eksempel: socialt netværk, aggregatorer, SaaS-platforme (software som en cloud-tjeneste), markedspladser
Hvis du har en butik eller webservice, ved du, at den er langsom, og folk forlader, du vil gøre det hurtigere, du forstår værdien af kunder og er klar til at betale over en million rubler for en opgradering.
Du har en mobilapplikation, der bruger webstedets API, men webstedet er langsomt og har fuldstændig genindlæsning af indhold, når du flytter mellem sider
MOD
Hvis din målgruppe ikke bruger moderne browsere og enheder.
For eksempel: specifikke virksomhedsområder, såsom udvikling af interne systemer til banker, medicinske institutioner og uddannelse.
Du udfører dine hovedaktiviteter offline og er ikke klar til at levere nogen tjenester online, og du skal blot tiltrække kunder.
Hvis du har en netbutik eller webservice, der allerede sælger godt, ser du ikke kundestrøm eller klager
Hvis du har en fungerende applikation, der ikke kan tilpasses til SPA, og du bare skal omskrive alt fra bunden og bruge andre teknologier, og du er ikke klar til at bruge flere millioner på dette.
For eksempel: Der er et indrammet websted eller en slags hjemmeskrevet gammel, monolitisk kode.
Progressive webapplikationer
Progressive webapplikationer er et produkt af den fælles udvikling af en native applikation og en hjemmeside. I det væsentlige er dette en webapplikation, der ser ud og opfører sig som en ægte indbygget applikation, kan modtage push-meddelelser, arbejde i offlinetilstand osv. I dette tilfælde behøver brugeren ikke at downloade applikationen fra AppStore eller Google Play, men blot gemme den på skrivebordet.
Som en teknologi eller tilgang til udvikling har PWA udviklet sig siden 2015 og har for nylig vundet enorm popularitet inden for e-handelsområdet.
Nogle eksempler fra det virkelige liv:
- sidste år var Best Western River North-hotellet i stand til at øge omsætningen med 300 % efter lanceringen af en ny PWA-aktiveret hjemmeside;
- Arabisk Avito OpenSooq.com var, efter at have oprettet PWA-support på sin hjemmeside, i stand til at øge besøgstiden på siden med 25 % og antallet af kundeemner med 260 %;
- den berømte datingtjeneste Tinder var i stand til at reducere indlæsningshastigheden fra 11.91s til 4.69s ved at udvikle en PWA; desuden vejer applikationen 90% mindre end dens oprindelige Android-modstykke.
Det faktum, at det er værd at være opmærksom på denne teknologi, indikeres også af, at en af de største motorer til at skabe e-handelsprojekter, Magento, lancerede en tidlig udviklingsversion af PWA Studio i 2018. Platformen giver dig mulighed for at skabe en React-baseret frontend ud af boksen til dine e-handelsløsninger med PWA-support.
Råd til dem, der allerede har et internetprojekt eller bare en idé til en ny tjeneste med understøttelse af mobile enheder: skynd dig ikke med at skrive en fuldgyldig indbygget applikation, men se først på PWA-teknologien. Dette kan være den bedste værdi for pengene løsning til dit produkt.
Lidt fra praksis. For at oprette en simpel indbygget mobil nyhedsapplikation, forudsat at du allerede har en færdiglavet REST-server, har du brug for cirka 200-300 mandetimer pr. platform. Med den gennemsnitlige markedspris for en times udvikling på 1500-2000 rubler/time, kan en applikation koste omkring 1 million rubler. Hvis du udvikler en webapplikation med fuld understøttelse af PWA: push notifikationer, offline mode og andet godt, så 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 det faktum, at du ikke skal betale gebyrer for placering i applikationsbutikker.
Serverless
Dette er en anden moderne tilgang til udvikling. På grund af navnet tror mange mennesker, at dette er virkelig serverløs udvikling, der er ingen grund til at skrive back-end-kode, og enhver front-end-udvikler kan oprette en fuldgyldig webapplikation. Men det er ikke sandt!
Når du opretter en serverløs applikation, har du stadig brug for en server og en database. Den største forskel ved denne tilgang er, at back-end-koden præsenteres i form af cloud-funktioner (et andet navn for serverløs er FaaS, fungerer som en tjeneste eller Functions-as-a-Service) og gør det muligt for applikationen at skalere hurtigt og let. Når man laver en sådan applikation, kan udvikleren fokusere på forretningsproblemer og ikke tænke på skalering og opsætning af infrastrukturen, hvilket efterfølgende fremskynder applikationsudviklingen og reducerer dens omkostninger. Desuden vil den serverløse tilgang hjælpe dig med at spare på serverleje, da den bruger nøjagtigt så mange ressourcer, som det er nødvendigt for at fuldføre opgaven, og hvis der ikke er nogen belastning, så bliver servertiden slet ikke brugt og ikke betalt for.
Eksempelvis var det store amerikanske medieselskab Bustle i stand til at reducere hostingomkostningerne med mere end 60 % ved skiftet til Serverless. Og Coca-Cola-virksomheden var, da de udviklede et automatiseret system til salg af drikkevarer gennem salgsautomater, i stand til at reducere hostingomkostningerne fra $13000 til $4500 om året ved at skifte til Serverless.
I løbet af de sidste par år er Serverless på grund af dets nyhed og begrænsninger hovedsageligt blevet brugt til små projekter, startups og MVP'er, men i dag, takket være udviklingen af software, alsidigheden og kraften i servercontainerisering, dukker der værktøjer op, der giver dig mulighed for at fjerne begrænsninger, forenkle og fremskynde udviklingen af cloud-applikationer.
Dette betyder, at virksomhedsscenarier, hvor cloud-modernisering tidligere blev anset for umuligt (for eksempel for edge-enheder, data i transit eller stateful-applikationer), nu er en realitet. Gode værktøjer, der viser meget lovende, er kNative og Serverless enterprise.
Men på trods af alt dette er Serverless ikke en sølvkugle til udvikling af webapplikationer. Som enhver anden teknologi har den sine fordele og ulemper, og du skal vælge dette værktøj med forståelse og "ikke slå søm med et mikroskop", bare fordi det er mere teknologisk avanceret.
For at hjælpe dig med at finde ud af det, er her nogle eksempler på, hvornår du måske vil overveje serverløs, når du udvikler en ny eller forbedrer en eksisterende webservice:
- Når belastningen på serveren er periodisk, og du betaler for ledig kapacitet. For eksempel havde vi en klient med et netværk af kaffemaskiner, og det var nødvendigt at behandle forespørgsler og indsamle statistik kun et par hundrede eller tusinde gange om dagen, og om natten faldt antallet af forespørgsler til flere dusin. I dette tilfælde er det meget mere effektivt kun at betale for den faktiske brug af ressourcer, så vi foreslog og implementerede en løsning på Serverless;
- Hvis du ikke planlægger at dykke ned i de tekniske detaljer i infrastrukturen og betale for meget for opsætning og vedligeholdelse af servere og en balancer. For eksempel, når du udvikler en markedsplads, ved du ikke præcis, hvad trafikken vil være, eller omvendt - du planlægger en masse trafik, og for at din applikation er sikker på at modstå belastningen, så er Serverless et glimrende valg.
- Hvis du har brug for at udføre nogle streaminghændelser i hovedapplikationen, skal du skrive sidedata i tabeller, udføre nogle beregninger. For eksempel indsamle analytiske data om brugerhandlinger, behandle dem på en bestemt måde og gemme dem i en database;
- Hvis du har brug for at forenkle, forene eller fremskynde den aktuelle drift af applikationen. Opret fx præstationsforbedrende tjenester til at arbejde med billeder eller videoer, når brugeren uploader video til skyen, og en separat funktion håndterer omkodning, mens hovedserveren fortsætter med at fungere som normalt.
Hvis du skal behandle begivenheder fra tredjepartstjenester. For eksempel behandle svar fra betalingssystemer eller omdirigere brugerdata til CRM for at fremskynde behandlingen af anmodninger fra potentielle kunder
Hvis du har en stor applikation, og nogle dele af applikationen kan implementeres mere optimalt med et andet sprog end det primære. For eksempel har du et projekt i Java og du skal tilføje ny funktionalitet, men du har ikke frie hænder, eller implementering på et givet sprog kan tage længere tid og der allerede findes en løsning på et andet sprog, så kan Serverless hjælpe også med dette.
Dette er ikke hele listen over værktøjer og teknologier, der fortjener opmærksomhed; Jeg har bare delt, hvad vi selv bruger hver dag i vores arbejde og ved præcis, hvordan de kan hjælpe forretningen.
Kilde: www.habr.com