Echtzeit

Zeit, das seltsame Konzept, das von uns geschaffen wurde, um zu beschreiben, wie Veränderungen unsere Wahrnehmung der Welt beeinflussen. Auch wenn es nur ein Konzept ist, unser Leben dreht sich darum und daher ist es wichtig, es zu berücksichtigen. Software-Engineering und -Entwicklung unterscheiden sich nicht. Wo das Internet an erster Stelle steht, ist es heutzutage undenkbar, eine Web-App (oder eine andere Anwendung) zu entwickeln und auf eine Schaltfläche zum erneuten Laden/F5/Strg+r zu klicken, um die neuesten Daten zu erhalten. Unsere Anwendungen müssen echtzeitfähig sein.
Non-Profit Echtzeitanwendung (RTA), fragen Sie?

Es ist eine Anwendung, die das Gefühl der Unmittelbarkeit vermittelt, zB wenn Benutzer A einige Daten in der Anwendung ändert, wird diese Änderung allen Benutzern in kürzester Zeit bekannt sein, ohne dass die Anwendung neu geladen werden muss.

Darüber hinaus ist das Latenzkriterium, das die Lieferverzögerungen der Daten bei einer Anwendung (Internet, Datenverarbeitung usw.) beeinflusst, sehr wichtig, wenn wir eine Echtzeitanwendung implementieren möchten. Je nachdem, wie gut wir die Fristen einhalten können, fällt unsere Bewerbung in eine der drei folgenden Kategorien:

• Harte Echtzeit, wo wir jede einzelne Frist in unserer Bewerbung einhalten müssen. Andernfalls führt dies zu einem Totalausfall des Systems.
• Feste Echtzeit, wenn einige Fristen versäumt werden, ist tolerierbar. Alle Daten, die nach einer Frist eingehen, sind nutzlos, und folglich ist die Qualität der Bewerbungen umgekehrt proportional zur Anzahl der verpassten Fristen.
• Weiche Echtzeit, verringert sich die Nützlichkeit der nach Ablauf der Frist erhaltenen Daten und damit die Qualität des Systems.

Und die Frage, die sich stellt, ist: Wo ist das Web in all dem? Oder genauer gesagt, wo stehen Web-Apps in diesen drei Kategorien?
Nun, es sollte offensichtlich sein, dass Web-Apps nicht in die erste Kategorie eingeordnet werden können, da das Web immer Verzögerungen hat und es aufgrund der Internet-Entropie fast unmöglich ist, jede einzelne Deadline in unserer Anwendung sicherzustellen.
Eine Web-App kann jedoch in die letzteren Kategorien eingeordnet werden.
Nach all dem Gerede über RTA scheint es, dass heutzutage jede Anwendung eine Echtzeitkomponente beinhalten muss. Wie bereits erwähnt, möchten wir, dass unsere Anwendungen reaktiv sind. Wenn eine Änderung vorgenommen wird, muss sich ihre Wirkung auf alle Benutzer auswirken, die die Anwendung verwenden. Benachrichtigungen, Chatnachrichten, Newsfeed usw. All dies sind Beispiele für Echtzeit in unseren Anwendungen.
Der Aufbau von RTAs ist jedoch nicht unbedingt ein Kinderspiel. Dies bringt zusätzliche Komplexität in unsere Architekturen, da es mehr Ressourcen erfordert, was auch eine Synchronisierung zwischen diesen impliziert. Und die Art und Weise, wie wir mit unseren Daten umgehen müssen, kann auch ziemlich knifflig sein (die Reihenfolge zwischen Nachrichten, Verzögerungen, Verlust und Neuübertragung usw.).

Erstellen von Echtzeitanwendungen

Reden wir jetzt übers Geschäft!

Wie bauen wir Echtzeitanwendungen?

Komischerweise haben wir aus architektonischer Sicht bereits die Grundlagen, Server und Client. Der schwierige Teil ist jedoch die Kommunikation zwischen ihnen. Wir kommunizieren bereits mit dem Server über HTTP-Anfragen und der Server sendet HTTP-Antworten. Wir möchten aber auch, dass der Server uns Nachrichten schicken kann. Führen Sie Websockets und vom Server gesendete Ereignisse (SSE) ein.
Websockets und Server-Sent Events sind Möglichkeiten, einen irgendwie bidirektionalen Kommunikationspfad zwischen dem Server und den Clients zu erreichen.

Websockets

Websockets verwenden eine TCP-Verbindung (pro Websocket). Es ist ein aktualisiertes HTTP-Protokoll, das eine bidirektionale Kommunikation zwischen einem Web-Client und einem Web-Server mit geringem Overhead ermöglicht. (Gerechte Warnung, Websockets sind hier (bis jetzt) ​​keine Möglichkeit, HTTP zu ersetzen, bitte verwenden Sie keine Websockets, um Ihre üblichen Posts und Gets zu machen.)
Als Profi bietet uns Websockets eine Vollduplex-Kommunikation, die die meisten Firewalls ohne große Neukonfiguration passiert. Wir können jede Art von Daten austauschen, und es hat auch ein gutes Sicherheitsmodell (Herkunftsbasiertes Sicherheitsmodell).
Es gibt jedoch immer noch Proxys, die das Protokoll nicht unterstützen, und Websocket-Server müssen im Vergleich zu normalen Webservern anders optimiert werden.

Vom Server gesendete Ereignisse

SSE, das oft vernachlässigt wird, sind normale HTTP-Anforderungen und -Antworten, ähnlich wie Long-Polling ohne den übertriebenen Overhead. Der erste Request, der gesendet werden muss, muss jedoch einen Inhaltstyp Text/Event-Stream haben. Sobald diese Anfrage gesendet und der Server bestätigt hat, kann er nach Belieben Nachrichten an den Client senden.
Als Vorteil verwendet SSE allgemeines HTTP, Wiederverbindung und Ereignis-IDs werden von der Implementierung angegeben und es ist ein einfaches Protokoll.
Leider hat SSE keine Binärunterstützung und ist auf die maximale Anzahl von HTTP-Verbindungen beschränkt.

Websockets vs. SSE

Nachdem diese beiden Tools vorgestellt wurden, stellen sich folgende Fragen:

Wann sollte ich das eine oder das andere verwenden?
Ist einer besser als der andere?

Nun, es kommt darauf an (es ist nie wirklich so einfach, oder?).
Websockets werden, wie bereits gesagt, am besten verwendet, wenn wir wirklich einen bidirektionalen Pfad zwischen dem Server und dem Client wünschen, typischerweise wenn wir eine kollaborative App, ein Multiplayer-Spiel, einen Chat usw. erstellen.
Wenn wir nur Updates von unserem Server erhalten möchten, z. B. Benachrichtigungen, Update-Streams wie einen Feed, ist SSE großartig, da sie nicht viel Arbeit erfordern und die Arbeit erledigen.

Anerkennungen

Obwohl wir über den besten Weg gesprochen haben, Echtzeit zu erreichen, gibt es einige andere Tools, die erwähnenswert sind.
Echtzeitdatenbanken sind, wie der Name schon sagt, Datenbanken, die darauf vorbereitet sind, Daten nach den Prinzipien des Echtzeit-Computing zu verarbeiten, sodass die Daten bei Bedarf leicht an den Client gesendet werden können und im Allgemeinen mehr Daten verarbeiten. Beispiele für diese Art von Datenbanken sind RethinkDB, und Firebase bietet auch eine Echtzeitdatenbank an.

Anzeige Summam

Ich denke, es reicht für einen Artikel, nicht wahr? Als wir also über Echtzeit für die Web-Apps sprachen, kann die Echtzeitkomponente der Anwendung nur als weich oder fest beschrieben werden, und obwohl Echtzeit im Trend liegt und wirklich nützlich ist, kann sie es sein schwer zu programmieren/warten oder damit umzugehen. Schließlich sind sowohl Websockets als auch vom Server gesendete Ereignisse Möglichkeiten, Echtzeit in unseren Anwendungen zu erreichen. Wählen Sie sorgfältig, manchmal brauchen Sie vielleicht das eine oder andere. Wenn Ihre Anwendung eine vollständige bidirektionale Verbindung zwischen dem Server und dem Client erfordert, verwenden Sie Websockets. Wenn Sie nur Updates benötigen, verwenden Sie SSE.

Überprüfen Sie unbedingt meine GitHub Repo aus, um mit diesen beiden Tools zu spielen!

Vielen Dank für das Lesen dieses Artikels. Bitte zögern Sie nicht, Vorschläge für weitere Verbesserungen oder Korrekturen zu machen.
Geschrieben von Yoan Ribeiro