Bevezetés
A digitális átalakulás évről évre egyre több különböző élet- és üzleti területet érint. Ha egy vállalkozás versenyképes akar lenni, a hagyományos információs weboldalak már nem elegendőek; szükség van mobil- és webalkalmazásokra, amelyek nem csupán információt nyújtanak a felhasználóknak, hanem lehetőséget adnak különféle funkciók végrehajtására: termékek és szolgáltatások rendelésére, valamint eszközök biztosítására.
Például a modern bankok számára már nem elegendő egy információkat tartalmazó weboldal; online eszközökkel kell rendelkezniük ügyfeleik számára, mint például egy ügyfélkapu, ahol a felhasználók kezelhetik számláikat, befektetéseiket és kölcsöneiket. Még a kisvállalkozásoknak is, a konverzió növelése érdekében, kényelmes eszközökre van szükségük, mint például az orvosi vagy fodrászati időpontfoglalás, az asztalfoglalás egy étterem vagy egy gyerekszoba számára születésnapi bulihoz.
A vállalatok tulajdonosainak időben át kellene kapniuk az információt kényelmes formátumban cégeik állapotáról, például statisztikai adatok és elemzések gyűjtése a különböző termelési osztályok állapotáról, vagy az osztályok teljesítménye. Gyakran minden egyes osztály a saját módján gyűjti ezeket az adatokat, és akár különböző eszközöket is használhat, így a tulajdonosnak sok személyes időt kellene töltenie a dolgok kiderítésével, ami közvetve vagy közvetlenül befolyásolhatja a vállalat hatékonyságát és végső soron a nyereséget. Itt is segíthet a digitális átalakulás és egy web- vagy mobilalkalmazás fejlesztése.
A technológia nem áll meg, folyamatosan fejlődik, és ami néhány évvel ezelőtt aktuális volt, az ma már elavult lehet, vagy amit néhány évvel ezelőtt nem lehetett megtenni, az ma már valósággá vált. Számos modern eszköz áll rendelkezésre, amelyek gyorsabban és jobban segítik a web- és mobilalkalmazások létrehozását. Személyes megfigyeléseim és tapasztalataim alapján szeretném megosztani a saját nézőpontomat arról, hogy mely technológiák és eszközök lesznek a legkeresettebbek a közeljövőben, és miért érdemes őket figyelembe venni modern webalkalmazás készítésekor.
Single page application (SPA)
Határozzuk meg egy kicsit a terminológiát. A Single Page Application (SPA) egy olyan webalkalmazás, amelynek összetevői egyszer betöltődnek egy oldalon, és a tartalom szükség szerint kerül betöltésre. Amikor a felhasználó az alkalmazás szakaszai között navigál, az oldal nem töltődik újra teljesen, csak a szükséges adatok töltődnek be és jelennek meg.
Az egyoldalas alkalmazások jelentős előnyöket nyújtanak sebesség és használhatóság terén a klasszikus webalkalmazásokkal szemben. Az SPA lehetővé teszi, hogy a weboldalak működése olyan legyen, mint egy desktop alkalmazásé, újratöltések és jelentős késések nélkül.
Ha néhány évvel ezelőtt az egyoldalas alkalmazások szinte egyáltalán nem támogatták a keresőoptimalizálást, és főként személyes fiókok és adminisztrációs panelek létrehozására használták őket, ma már sokkal könnyebb egy teljes mértékben keresőoptimalizált (SEO) egyoldalas alkalmazást készíteni. A szerveroldali rendereléssel rendelkező egyoldalas alkalmazások használatával ez a probléma teljesen eltűnt. Más szavakkal, ez egy ugyanolyan egyoldalas alkalmazás, de az első kéréskor a szerver nem csak adatokat generál, hanem egy kész megjelenítésre alkalmas HTML oldalt hoz létre, és a keresőmotorok kész oldalakat kapnak minden meta-információval és szemantikai jelöléssel.
A kliensoldali webalkalmazások fejlesztésének eszközeivel együtt az egyoldalas alkalmazások létrehozása és bevezetése az elkövetkező években egyre növekedni fog. Ha van egy régi alkalmazása, amely elavult és lassan működik, ráadásul teljes oldalletöltésekkel ugrál a szakaszok között, akkor idén bátran frissítse gyors egyoldalas alkalmazásra – most jó idő van, a technológiák már lehetővé teszik ezt viszonylag gyorsan és hatékonyan.
Jó dolog, ha modern és gyors weboldala van, de szeretném őszintén megmondani: nem minden alkalmazást lehet könnyen egyoldalasra átállítani, és az átállás nem olcsó mulatság! Ezért fontos megérteni, hogy kinek és miért van szüksége egy ilyen átállásra.
Hogy segítsenek Önnek eligibilis esetekkel kapcsolatban, az alábbi táblázatban néhány példát mutatok be, amikor az SPA fejlesztése vagy átállása indokolt és mikor nem.
ZA
Ha modern, gyors alkalmazást szeretne létrehozni, amelyet nemcsak webes változatban, hanem mobil vagy akár asztali változatban is használhatnak, miközben minden folyamat és számítás távoli vagy felhőalapú szervereken zajlik. Ráadásul úgy, hogy az összes ügyfél egyetlen interaktív felületen keresztül fér hozzá, és ne kelljen minden módosítást elvégezni a szerveroldali kódon, amikor új ügyfelet adunk hozzá.
Például: közösségi hálózatok, aggregátorok, SaaS platformok (szoftver mint szolgáltatás), piacterek.
Ha van boltja vagy webszolgáltatása, és tudja, hogy lassú, és az emberek elhagyják, szeretné gyorsabbá tenni, tudja az ügyfélérték jelentőségét, és készen áll arra, hogy egymillió rubelért fejlesztést kérjen.
Van egy mobilalkalmazása, amely az oldal API-ját használja, de az oldal lassú, és teljes tartalomfrissítésekkel váltanak az oldalak között.
ELLEN
Ha a célközönsége nem használ modern böngészőket és eszközöket.
Például: specifikus vállalati területek, mint például belső rendszerek fejlesztése bankok, egészségügyi intézmények és oktatás számára.
A fő tevékenységét offline végzi, és nem hajlandó semmilyen szolgáltatást online biztosítani, és csak ügyfeleket szeretne vonzani.
Ha van egy online boltja vagy webszolgáltatása, amely már jól teljesít, nem látja az ügyfelek elvándorlását és panaszokat.
Ha van egy működő alkalmazása, amelyet lehetetlenség SPA-ra adaptálni, és mindent újra kellene írnia más technológiák használatával, de nem áll készen arra, hogy erre több milliót költsön.
Például: van egy dobozos weboldala vagy valamilyen régi, monolitikus kódja.
Progresszív Webalkalmazások
A Progresszív Webalkalmazások (PWA) a natív alkalmazások és a weboldalak közös evolúciójának termékei. Lényegében ez egy webalkalmazás, amely úgy néz ki és viselkedik, mint egy valódi natív alkalmazás, képes push értesítéseket fogadni, offline módban működni stb. Eközben a felhasználónak nem kell alkalmazást letöltenie az App Store-ból vagy a Google Play-ből, elég, ha egyszerűen a munkaasztalra menti.
A PWA technológia vagy megközelítés 2015 óta fejlődik, és az utóbbi időben hatalmas népszerűségnek örvend az e-kereskedelem területén.
Néhány valós példa az életből:
- Tavaly a Best Western River North hotel, miután elindította új PWA-t támogató weboldalát, 300%-kal tudta növelni bevételét;
- Az arab Avito OpenSooq.com 25%-kal tudta növelni a weboldal látogatási idejét és 260%-kal a leadek számát, miután PWA támogatást hozott létre a weboldalán;
- A népszerű társkereső szolgáltatás, a Tinder, 11.91 másodpercről 4.69 másodpercre csökkentette a betöltési idejét, miután kifejlesztett egy PWA-t, ráadásul az alkalmazás 90%-kal kisebb, mint natív Android megfelelője.
A PWA technológia iránti figyelem értékét egyértelműen bizonyítja, hogy a Magento, amely a legnagyobb e-kereskedelmi projektek létrehozására szolgáló motor, 2018-ban elindította a PWA Studio korai fejlesztői változatát. A platform lehetővé teszi, hogy "dobozból" kész frontendot hozzunk létre React alapokon az e-kereskedelmi megoldásokhoz PWA támogatással.
Tanács azok számára, akiknek már van internetes projektjük vagy csak egy új mobil szolgáltatás ötlete: ne rohanjon teljes natív alkalmazást írni, inkább nézzen utána a PWA technológiának. Lehet, hogy ez lesz a legjobb ár-érték arány a termékéhez.
Egy kis gyakorlati példa. Ahhoz, hogy egy egyszerű natív hírolvasó mobil alkalmazást hozzunk létre, amennyiben már van kész REST szerver, körülbelül 200-300 munkaórára van szükség minden platform esetében. A piacon elérhető átlagos óradíj 1500-2000 rubel/óra, így az alkalmazás körülbelül 1 millió rubelbe kerülhet. Ha teli PWA támogatással rendelkező webalkalmazást fejlesztünk: push értesítésekkel, offline üzemmóddal és egyéb előnyökkel, akkor a fejlesztés 200-300 munkaórát vesz igénybe, de a termék azonnal elérhető lesz minden platformon. Tehát körülbelül 2-szeres megtakarítást jelent, nem is beszélve arról, hogy nem kell díjat fizetnie az alkalmazásboltokban való megjelenésért.
Serverless
Ez egy újabb modern megközelítés a fejlesztésben. A név miatt sokan azt gondolják, hogy valóban szerver nélküli fejlesztésről van szó, hogy nincs szükség back-end kód írására, és bármely front-end fejlesztő képes lesz teljessé tenni egy webalkalmazást. De ez nem igaz!
Serverless alkalmazás létrehozásakor a szerverre és az adatbázisokra továbbra is szükség van. A megközelítés fő különbsége abban rejlik, hogy a back-end kód felhőfunkciókként van megvalósítva (a serverless másik neve a FaaS – funkciók mint szolgáltatás) és lehetővé teszi az alkalmazás gyors és egyszerű skálázását. Egy ilyen alkalmazás létrehozásakor a fejlesztő a üzleti feladatokra összpontosíthat, anélkül, hogy a skálázáson és az infrastruktúra beállításán kellene gondolkodnia, ami végső soron felgyorsítja az alkalmazás fejlesztését és csökkenti a költségeit. Továbbá, a Serverless megközelítés segít a bérleti díjak megtakarításában szerverek, mivel pontosan annyi erőforrást használ, amennyire a feladat teljesítéséhez szükség van, és ha nincs terhelés, akkor a szerveridő egyáltalán nem használódik el és nem is fizetendő.
Például a Bustle, egy nagy amerikai médiacég, több mint 60%-kal csökkentette kiadásait hosztolást a Serverless-re való átállással. A Coca-Cola pedig, az automatizált italvending rendszer fejlesztésekor, képes volt a hosting költségeit 13 000 dollárról 4 500 dollárra csökkenteni évente a Serverless-ra való áttérés által.
Az ut últimos pár évben, a újdonsága és korlátai miatt a Serverless főként kicsi projektek, start-upok és MVP-k számára volt használva, de ma, a szoftverek fejlődésének, a sokoldalúságnak és a szerverkonténerek erejének köszönhetően olyan eszközök jelennek meg, amelyek lehetővé teszik a korlátok eltávolítását, és egyszerűsítik, gyorsítják a felhőalkalmazások fejlesztését.
Ez azt jelenti, hogy a vállalati üzleti forgatókönyvek, amelyekben a felhőmodernizáció korábban lehetetlennek tűnt (például az adatátviteli perifériák vagy állapotmegőrző alkalmazások esetében), most valósággá váltak. A kNative és a Serverless enterprise jó kilátású eszközök.
De mindez mellett a Serverless nem a webalkalmazások fejlesztésének ezüst lövedéke. Mint minden más technológiának, ennek is megvannak a maga előnyei és hátrányai, és óvatosan kell választani ezt az eszközt, „nem szabad mikroszkóppal szöget ütni”, csak azért, mert technológiailag fejlettebb.
Hogy segítsünk tisztázni, itt van néhány példa, amikor érdemes elgondolkodni a Serverless használatán új webszolgáltatás fejlesztése vagy a meglévők javítása során:
- Amikor a szerver terhelése időszakosan változik, és csak a tényleges használatért kell fizetnie. Például volt egy ügyfelünk, akinek kávéautomata hálózata volt, és naponta csak néhány száz vagy ezer alkalommal kellett feldolgozni a kéréseket, míg éjjel a kérések száma néhány tucatnyira csökkent. Ebben az esetben sokkal hatékonyabb csak az erőforrások tényleges használatáért fizetni, ezért javasoltunk és megvalósítottunk egy Serverless megoldást;
- Ha nem tervezi, hogy belemerül a technikai részletekbe, és nem akar túl sokat fizetni a szerverek és a terheléselosztók beállításáért és karbantartásáért. Például egy piactér fejlesztésekor pontosan nem tudja, mekkora lesz a látogatottság, vagy éppen ellenkezőleg — tervez egy nagy látogatottságot, és biztos akar lenni abban, hogy az alkalmazása biztosan elbírja a terhelést, akkor a Serverless remek választás.
- Ha szükség van valamilyen adatfolyami esemény végrehajtására a fő alkalmazásban, mellékadatok rögzítésére táblákba, vagy valamilyen számítás elvégzésére. Például felhasználói tevékenységekről származó analitikai adatok gyűjtése, azok meghatározott módon történő feldolgozása és adatbázisba való mentése;
- Ha egyszerűsíteni, egységesíteni vagy felgyorsítani kell az alkalmazás jelenlegi működését. Például teljesítménynövelő szolgáltatásokat létrehozni képek vagy videók kezelésére, amikor a felhasználó videót töltene fel a felhőbe, és a transcodingot egy külön funkció intézi, miközben a fő szerver a szokásos módon működik.
Ha külső szolgáltatások eseményeit kell feldolgozni. Például a fizetési rendszerek válaszainak feldolgozása, vagy a felhasználói adatok CRM-be való átirányítása a potenciális ügyfelek kérelmeinek gyorsabb feldolgozása érdekében;
Ha egy nagy alkalmazása van, és az alkalmazás egyes részeit optimálisabban lehet megvalósítani egy másik nyelven, mint az alap. Például ha a projektje Java nyelven készült, és új funkciót kell hozzáadnia, miközben szabad kezek nincsenek, vagy a megvalósítás ezen a nyelven több időt venne igénybe, és van már megoldás egy másik nyelven, akkor a Serverless ebben is segíthet.
Ez messze nem egy teljes lista azokról az eszközökről és technológiákról, amelyek érdemesek a figyelemre, csupán azt osztottam meg, amit mi magunk nap mint nap használunk a munkánk során, és pontosan tudjuk, hogyan segíthetnek az üzletnek.
Forrás: habr.com
