5 начина за създаване на приложения в реално време с JavaScript

Имаше момент, в който не очаквахме твърде много от уеб страниците. Което ми напомня, уебсайтът за филми Space Jam все още е в интернет в оригиналния си вид. И използва фреймсет. Не iFrames. РАМКИ .

Space Jam

SPACE JAM, знаци, имена и всички свързани означения са търговски марки на Warner Bros. © 1996 www.warnerbros.com

Warner Bros има няколко внимателно използвани копия на Dreamweaver MX.

Това беше 1996 г. Това е 2019 г. Времената се промениха и потребителите очакват много повече от уебсайтовете. Те не просто очакват от тях да изглеждат добре, те очакват да са пълни с приложения и това включва реално време.

Приложения в реално време

Приложенията в реално време са тези, които реагират на промени навсякъде в системата на свързаното приложение - не само тези, направени от текущия потребител.

Каноничният пример за реално време е приложение за съобщения. Като когато изпратите на група приятели текстово съобщение за събиране за крила в петък. След това актуализирайте всеки минута по минута за напредъка ви от работата до бара. Благодаря, Тревор. Сега всички сме попаднали в ада за уведомяване, за който не сме се регистрирали. САМО ИСКАХ НЯКОИ КРИЛА.

Що се отнася до мрежата, има няколко различни модела, технологии, библиотеки и услуги, които можете да използвате, за да получите функционалността в реално време, която обикновено е запазена за родните приложения. Наскоро седнах с Антъни Чу, който ми даде 5 начина, по които можете да създавате приложения в реално време в JavaScript.

Антъни Чу #MSIgniteTheTour (@nthonyChu) | Twitter

Последните туитове от Антъни Чу #MSIgniteTheTour (@nthonyChu). Cloud Advocate @Microsoft. Azure, ASP .NET, Node.js ... twitter.com

1. Дълго анкетиране

Това е, когато приложението изисква актуализации от сървъра по график. Приложението „анкетира“ сървъра.

Това е нетният еквивалент на децата, които питат „вече ли сме там?“ на всеки пет минути. Изглежда, че вече сме там, хлапе? Попитайте ме още веднъж и ви се заклевам, че ще хвърля това копие на „Филмът за пчелите“ в канавка и ще можете да гледате през прозореца тревата, както правехме, когато бях дете.

Дългото анкетиране може да се приложи ръчно с всяка HTTP библиотека на JavaScript, като jQuery или Axios. Никога всъщност не съм прилагал това сам. Когато правех някои изследвания за тази статия, открих, че най-добрият начин да направите това е да използвате рекурсивна функция с setTimeout. Това е така, защото използването setIntervalне отчита заявки, които са неуспешни или времето за изчакване. Може да се окажете с куп ajax повиквания, които всички се обработват извън ред.

Ето пример от много хубавата статия за Tech Octave.

(function poll(){ setTimeout(function(){ $.ajax({ url: "server", success: function(data){ //Update your dashboard gauge salesGauge.setValue(data.value); //Setup the next poll recursively poll(); }, dataType: "json"}); }, 30000); })();

Има и библиотеки като pollymer (да не се бърка с Polymer), които са специално за дълго анкетиране. Вземи го? „Анкета“ ymer? Защото анкети? Това нещо включено ли е?

фенут / полимер

Универсална AJAX / библиотека с дълги анкети. Допринесете за развитието на fanout / pollymer, като създадете акаунт в GitHub. github.com

Дългото проучване е добро, защото работи във всеки браузър; дори супер старите. Лошо е, защото е супер неефективно и не е точно „в реално време“. Той също така има някои странни случаи на край (като грешки в заявките), които трябва да програмирате, както вече видяхме setInterval.

По-добра алтернатива на дълго анкетиране са изпратени от сървъра събития или SSE.

2. Изпратени от сървъра събития

Сървърно изпратени събития (SSE) е подобен на дългото анкетиране, доколкото клиентът иска от сървъра информация. Голямата разлика е, че при SSE сървърът просто поддържа връзката отворена. Когато се случи събитие и има информация за изпращане до клиента, сървърът изпраща събитие до клиента.

Изпратени от сървъра събития

Традиционно уеб страницата трябва да изпрати заявка до сървъра за получаване на нови данни; тоест страницата иска данни от ... developer.mozilla.org

Обратно към нашата аналогия с „пътуване от ада”, това би било като ако детето каже „Още ли сме там?” И след това търпеливо изчака отговора ви. Четири възвишени часа мълчание по-късно пристигате на дестинацията, обръщате се и казвате „да“. Това е най-нереалният сценарий, който съм измислял през живота си.

SSE е част от EventSourceAPI на браузъра . Имайте предвид, че според caniuse.com нито IE 11, нито Edge поддържат SSE. Това го прави доста трудна технология за избор, колкото и интересна да е тя.

Добрата новина е, че почти всеки браузър поддържа Web Sockets.

3. Уеб гнезда

Web Sockets е технология, която улеснява истински двупосочен канал за комуникация между клиент и сървър. За разлика от Server-Sent Events, което е само комуникация от сървър към клиент, Web Sockets могат да се използват за комуникация и в двете посоки.

Уеб сокетите са доста многословни. Те всъщност не са от типа API, с който искате да създавате приложения. Подобно на това можете да направите HTTP заявка с XHR обекта, но OMG NO. Потърсих в Google „Пример за уеб сокет на PHP“ и намерих този doozy от PHP документите. Намалих мащаба докрай в Chrome и едвам получих всичко на една екранна снимка.

И това е САМО сървърната част. Все още трябва да свържете браузъра.

Така че ... това е не за мен.

За щастие има много библиотеки, които абстрахират Web Sockets още повече, така че не е нужно да пишете нищо от това. Една от тези библиотеки се нарича „SignalR”.

4. SignalR

SignalR is a library that implements Web Sockets both in JavaScript AND .NET. On the server, you create what is known as a “hub” in SignalR. This hub sends and receives messages from clients.

Clients then connect to the hub (using the SignalR JavaScript library) and respond to events from the hub, or send their own events into the hub.

SignalR also falls back to long-polling whenever Web Sockets is unavailable. Although that’s not super likely unless you’re using IE 9 or lower.

Here is an example of setting up SignalR on the server…

using System; using System.Web; using Microsoft.AspNet.SignalR; namespace SignalRChat { public class ChatHub : Hub { public void Send(string name, string message) { // Call the broadcastMessage method to update clients. Clients.All.broadcastMessage(name, message); } } }

OK, ok. I know this is not an apples to apples comparison with the PHP example from above, but I’m trying to make a point here. Just go with it. Do it for me. I’m having a rough morning.

So SignalR makes it more fun to program Web Sockets, but you know what’s even more fun than programming them? Not programming them.

5. Azure SignalR

Often, when we want to set up real-time applications, building out a Web Socket server isn’t exactly a value-added activity. We do it, but only because we have to to get the real-time. We’d prefer that it “just worked”.

Azure SignalR is exactly that. It is a SignalR Hub that you can consume on demand as a service. That means that you only have to send and respond to events — which is what you’re after in the first place.

What is Azure SignalR

An overview of the Azure SignalR service.docs.microsoft.com

You create the SignalR Hub in Azure as an Azure Service, and then you just connect to it from the client and send/receive messages.

And now you know….

Check out the interview below with Anthony. We shot this one in Vegas while we were both at a conference and had a good time with a wig that I bought at Party City. Best 8$ I ever spent.