Videó: Tones and I - Dance Monkey (Lyrics) (November 2024)
Az egyik dolog, amelyet az elmúlt néhány hónapban érdekesnek találtam a fejlesztési világban, az, hogy a modern alkalmazások miként mozognak vissza azáltal, hogy több intelligenciát az ügyfélbe helyeznek a szerver helyett. Az ügyfél-szerver modell természetesen semmi új: ez a módja annak, ahogy a hagyományos alkalmazásokat évek óta építik, a gazdag kliens alkalmazásokkal a szerver oldali alkalmazásokkal beszélgetve. A web és még a Web 2.0 korszakában azonban a hangsúly olyan webes alkalmazásokra költözött, amelyekben az intelligencia nagy része a webszerveren volt (általában Java alapú alkalmazáskiszolgálón), és az ügyfél csak egy egyszerű weboldal volt a egy böngésző, ahol minden egyes kattintás után új oldalt töltött be.
A közelmúltban azonban a HTML5, CSS és különösen a JavaScript érlelése arra készteti a fejlesztőket, hogy valódi intelligenciát és valós feldolgozást tegyenek maga a weboldalon. Különösen az ügyféloldali JavaScript-alapú keretek megjelenését láttuk, amelyek megkönnyítik az intelligens felhasználói felületek létrehozását, amelyek teljes mértékben működnek egy modern webböngészőben. Az érintett böngészők általában a Webkit motoron alapulnak, beleértve a Chrome-ot és a Safari-t, de úgy tűnik, hogy az alkalmazások többsége jól működik a Firefox és az Internet Explorer jelenlegi verzióiban is. Végül egy összetettebb weboldalt állít fel, amely dinamikusan megváltozik, és szükség szerint kihúzza az adatokat a szerverről.
Úgy tűnik, hogy különösen a három MVC-keretrendszer kapja a legnagyobb figyelmet: Backbone.js, Ember.js és Angular.js. (Az MVC a model-view-controller-t jelenti - lényegében a webes kliens számítástechnika mögött meghúzódó architektúra. A "js" a JavaScript-t jelenti.) Lényegében ez az elmúlt évtizedben népszerű AJAX (aszinkron JavaScript és XML) megközelítés növekedése, vagy igen, de sokkal érett és szinte szabványosított. Az ötlet az, hogy minél több állapotot és intelligenciát tegyen a böngészőbe, majd a böngészőt csatlakoztassa a REST API-khoz a szerver oldalon.
A gerinc talán a legalapvetőbb és minimális e keretek közül; sok népszerű webhely különféle mértékben használja. Az Ember a Sproutcore nevű keretből nőtt ki, amelyet az Apple támogatta, és egy sokkal átfogóbb keret, amelynek célja az asztali stílusú alkalmazások készítése. Gyakran használják a Bootstrap-rel - HTML és CSS sablonkészlet, amelyet eredetileg a Twitter alkalmazottai készítettek. A szögletes a Google alternatívája, amely úgy tűnik, hogy valahol a kettő között van - egyesek szerint ez kissé rugalmasabb vagy legalábbis "kevésbé véleményes", mint az Ember, de átfogóbb, mint a gerinc. (Megjegyzés: A Google arra készteti a fejlesztőket, hogy használják az Angular funkciót a kódolás minőségének javítása érdekében, de belsőleg valójában más, tulajdonosi keretsorozatot használnak.) Még a Microsoft is hozzátette a Visual Studiohoz horgokat ezekre a keretekre.
Mivel ez a web, tucatnyi alternatíva létezik. Az egyik legérdekesebb, amiről a közelmúltban hallottam, a Meteor, amelyet úgy terveztek, hogy a JavaScript-rel működjön mind az ügyfél, mind a szerver oldalán. De ez még mindig nagyon korai, és még nem ismerek valós felhasználókat. Időközben több fejlesztő játszik a Node.js-rel, amelyet gyakran kiszolgálóoldali JavaScript megvalósításhoz használnak.
Az ilyen keretek előnye egyértelműnek tűnik. A gazdag web-kliens alkalmazások sokkal hatékonyabbak, mint a vékony kliens alkalmazások, ahol minden a szerveren fut, jobb felhasználói felületet kínálnak, és offline információ lehetőségét kínálják. Ezeknek a kereteknek a felhasználásával sokkal gyorsabban hozhat létre gazdag webes ügyfélalkalmazásokat, mint amennyire lehetett volna, mindent a nulláról építve, és kihasználva mindegyikük körül fejlődő közösségeket.
Talán a legfontosabb: hozhat létre mobil alkalmazásokat, amelyek különböző eszközökre méretezhetők anélkül, hogy konkrét natív alkalmazásokat kellene írni. Még mindig jó érv szól a natív alkalmazások számára, amelyek közvetlenebbül foglalkoznak az egyes platformok sajátosságaival. Azonban sok fejlesztő úgy találta, hogy az ilyen keretek drámai módon felgyorsíthatják a platformok közötti fejlesztést, különösen, ha olyan elemekkel együtt használják, mint például a PhoneGap, az Adobe által megvásárolt és az Apache Cordova projektbe nyílt forrású mobilkeret.
A Mobile természetesen magával hozza a saját korlátozásait, ideértve a processzorok sebességét, és ami még ennél is fontosabb: a kapcsolat gyorsasága, és néha hiánya. Ennek egyik oka az, hogy az emberek kedvelik az alkalmazásokat a weblapokon, az, hogy gyakran letölthetik az alapvető funkciókat Wi-Fi vagy gyors kapcsolaton keresztül, és csak a szükséges adatokat tölthetik le, és nem a teljes kialakítást. Az olyan csomagok, mint a PhoneGap, megoldják ezt a problémát azáltal, hogy a JavaScriptet letöltik egy letöltött alkalmazásba.
Az ilyen keretekkel kapcsolatban azonban vannak más kérdések is. A meghatározás szerint az ügyféloldalon végzett további számítások megnövelik a bonyolultságot egy egyszerű kiszolgálóra épülő alkalmazáshoz képest, sőt, a régi ügyfél-kiszolgáló modell néhány hátránya visszatér. A fejlesztőknek mindkét oldalnak irányítaniuk kell az államot. Két helyen lévő kód azt jelenti, hogy mindkét helyen a biztonságra kell összpontosítania. Mivel egy fejlesztői csoportban gyakran dolgoznak bizonyos ügyfelek az ügyfélen, míg mások a szerveren, további kommunikációs problémák merülnek fel. Másrészt néhány kliens-szerver régebbi kérdése nem tér vissza, ehelyett Ön megtartja a webes szoftverek előnyeit. Ez sokkal inkább a szabványok által vezérelt, a közösség által vezérelt világ, tehát nem vagy olyan függő az egyetlen szabadalmaztatott környezettől. Az ügyfél és a kiszolgáló oldali részek felosztásával tisztább, egyszerűbb kiszolgáló oldali megvalósítást is végezhet, amely éppen feldolgozást végez, és nem felhasználói felületet, és ennek eredményeként kevesebb erőforrást igényelhet. Ennek ellenére továbbra is megvan az az előnye, hogy egyszerre frissítheti az összes ügyfelet, mivel általában a böngésző betölti a kódot a szerverről, amikor az alkalmazást meghívják.
Világosan látjuk az intelligens webes ügyfelek felé történő elmozdulást - nem minden esetben, de sok új alkalmazásban. Sokkal nehezebb átvenni a régebbi alkalmazásokat, és áthelyezni őket ebbe a modellbe, ám ezek közül néhányat is látunk. Ez nem egészen a régi kliens-szerver modell, de egyre közelebb kerül.
