nicht angemeldet
REST API vs. Websockets
0 
Gunnar Bittersmann
0 
Der Martin
0 0 Der Martin
0 
Rolf B
REST API vs. Websockets
Okay, wie so oft wächst sich ein eigentlich nur als Gimmick gedachtes Detail zu einem Projekt innerhalb eines Projekts aus... :(
So wollte ich für ein (an und für sich ein REINES Singleplayer-) Spiel eine Bestenliste implementieren, die dann natürlich serverseitig aktualisiert werden muss.
Dazu böte sich prinzipiell ein Socket Server an, bei dem der Event Stream offen bleibt und keine gesonderten HTTP Requests erfolgen müssen - nur - steht sich das für?
So ein offener Event Stream ist ja doch ressourcenintensiv, soll heißen, wie viele Clients könnten da denn gleichzeitig überhaupt darauf zugreifen?
Ist das mit PHP überhaupt sinnvoll umzusetzen (stolpere nur über Node-JS Tutorials)?
Ich nehme an, bei "normalen" Hosting Providern ist da ziemlich bald mal das Ende der Fahnenstange erreicht (wenn sie es überhaupt zulassen), oder wie seht ihr das, hat sich das mittlerweile geändert?
Ich überlege ernsthaft, clientseitig einfach alle paar Sekunden einen fetch-Request abzuschicken, sobald der/die BenutzerIn sich die Bestenliste ansieht (was wäre da ein sinnvolles Intervall, das der Server auch bei 100+ Verbindungen verträgt?). Wäre das nicht "vernünftiger" a.k.a. nicht mit Spatzen auf Kanonen schießen?
Vielen Dank für eure Einschätzungen!
Hansi
-
@@Hansi
So wollte ich für ein (an und für sich ein REINES Singleplayer-) Spiel eine Bestenliste implementieren, die dann natürlich serverseitig aktualisiert werden muss. […]
Ich überlege ernsthaft, clientseitig einfach alle paar Sekunden einen fetch-Request abzuschicken, sobald der/die BenutzerIn sich die Bestenliste ansiehtNö, bei geänderter Bestenliste schickt der Server eine push notification, welche die Browser der Spielerïnnen dann auswerten. Wer die Bestenliste aktuell halten will, wird wohl dem Browser die Zustimmung dafür erteilen.
😷 LLAP
--
„Dann ist ja auch schrecklich, dass wir in einem Land leben, in dem nicht nur Bildungswillige leben, sondern auch hinreichende Zahlen von Bekloppten. Das darf ich so locker formulieren, ich bin ja jetzt Rentner und muss nicht mehr auf jedes Wort achten.“
— Joachim Gauck über Impfgegner-
Danke Gunnar!
...ja, war auch schon ein Gedanke.
Aber hängt sich meines Wissens an iOS auf :/
LG,
Hansi
-
-
Hallo,
Okay, wie so oft wächst sich ein eigentlich nur als Gimmick gedachtes Detail zu einem Projekt innerhalb eines Projekts aus... :(
nichts Ungewöhnliches, das habe ch auch schon oft erlebt. Ich versuche dann normalerweise, das Teilprojekt in eine Minimalumgebung auszugliedern und erstmal unabhängig vom Hauptprojekt zu entwickeln.
nur - steht sich das für?
Was ist denn das für eine Formulierung? Habe ich so noch nie gehört.
Ist das mit PHP überhaupt sinnvoll umzusetzen (stolpere nur über Node-JS Tutorials)?
IMO nein. PHP hat ein Zeitlimit für laufende Scripts. Ob das bei deinem Hoster auf 10, 30 oder 60 Sekunden eingestellt ist - egal, früher oder später schlägt es zu.
Ich überlege ernsthaft, clientseitig einfach alle paar Sekunden einen fetch-Request abzuschicken, sobald der/die BenutzerIn sich die Bestenliste ansieht (was wäre da ein sinnvolles Intervall, das der Server auch bei 100+ Verbindungen verträgt?). Wäre das nicht "vernünftiger" a.k.a. nicht mit Spatzen auf Kanonen schießen?
Warum alle paar Sekunden? Genügt es nicht, in dem Augenblick nachzufragen, in dem ein Spieler seine Runde beendet hat (oder eben die High-Score-Liste aufruft)?
May the Schwartz be with you
Martin--
Wenn ich den See seh, brauch ich kein Meer mehr.-
Warum alle paar Sekunden? Genügt es nicht, in dem Augenblick nachzufragen, in dem ein Spieler seine Runde beendet hat (oder eben die High-Score-Liste aufruft)?
Danke Martin!
Ja, prinzipiell um so ein Feedback ging es mir. ...Überlege, dann allerdings vielleicht zusätzlich eine Art "Zeitstempel" des letzten Updates zu implementieren, den der User per BUTTON sozusagen "refreshen" kann -
− aber es bleibt irgendwie dieser Beigeschmack - würdet ihr eine solche UX als professionell (oder zumindest nicht stümperhaft) erleben?
...vielleicht GANZ blöd formuliert: stellt euch vor, ihr produziert ein Spiel, das außer einer Bestenliste (bei der es sich per se schon um einen Afterthought handelt) keinerlei Multiplayer Interaktionsmöglichkeiten bietet - daher eigentlich im Sinne einer "klassischen Website" (ich client wollen Ressource, ich holen aktiv von Server, Server nix bidirektionale Kommunikation) zu verstehen ist - wie würdet ihr so eine Bestenliste arrangieren?
LG, Hans
-
Hallo Hans,
Warum alle paar Sekunden? Genügt es nicht, in dem Augenblick nachzufragen, in dem ein Spieler seine Runde beendet hat (oder eben die High-Score-Liste aufruft)?
Danke Martin!
Ja, prinzipiell um so ein Feedback ging es mir.
de nada. 😀
...Überlege, dann allerdings vielleicht zusätzlich eine Art "Zeitstempel" des letzten Updates zu implementieren, den der User per BUTTON sozusagen "refreshen" kann -
Das hört sich für mich gut an.
− aber es bleibt irgendwie dieser Beigeschmack - würdet ihr eine solche UX als professionell (oder zumindest nicht stümperhaft) erleben?
Mir ist es bedeutend lieber, wenn eine Webseite erst dann die angezeigten Daten aktualisiert, wenn ich ausdrücklich darum bitte.
...vielleicht GANZ blöd formuliert: stellt euch vor, ihr produziert ein Spiel, das außer einer Bestenliste (bei der es sich per se schon um einen Afterthought handelt) keinerlei Multiplayer Interaktionsmöglichkeiten bietet - daher eigentlich im Sinne einer "klassischen Website" (ich client wollen Ressource, ich holen aktiv von Server, Server nix bidirektionale Kommunikation) zu verstehen ist - wie würdet ihr so eine Bestenliste arrangieren?
Ich bin da vielleicht altmodisch - aber wie gesagt: Ich möchte die Aktualisierung angezeigter Daten nicht ohne mein Zutun haben (übrigens auch nicht bei native applications).
May the Schwartz be with you
Martin--
Wenn ich den See seh, brauch ich kein Meer mehr.-
Hallo Martin,
Aktualisierung angezeigter Daten
kommt auf die Daten an. Manche Daten müssen aktualisiert werden, damit sie ihren Sinn erfüllen.
Eine Bestenliste gehört meiner Meinung nach nicht dazu.
Mit einem normalen Webserver und PHP sind Websockets jedenfalls nicht realisierbar, das macht man über eigene Server (die man, wenn ich das richtig verstanden habe, durch einen Apache auch durchleiten kann). Ein node.js kann sowas, ja.
Push Notifications brauchen auf Client-Seite einen Serviceworker. Wie sie auf Serverseite funktionieren, dazu habe ich bisher noch keine richtige Erklärung gefunden. Dem Anschein nach implementiert man die Serverseite nicht selbst, sondern schickt die Notification an einen Push-Provider und der kümmert sich um die Verteilung. Das Blöde ist, dass sich alle Tutorien zu Push nur um die Clientseite kümmern, so, als wäre die Serverseite völlig unwichtig. Meine Unkenntnis der Sache beginnt schon bei der Frage, ob ich einen Push-Provider gegen Geld kaufen muss oder ob es das auch gratis gibt. Und wie da die Security ist - ich mag ja nicht bspw. Google als Push-Provider nutzen und die schreiben dann schön mit…
Rolf
--
sumpsi - posui - obstruxi-
ja, möchte hier nicht neunmalklug erscheinen, aber Push Notification sind wiederum ein ganz anderes Beast.
Push Notifications im Sinne von Verständigungen, wenn z.B. eine neue Nachricht reinkommt während die App nur im Hintergrund läuft (Bsp. WhatsApp oder besser noch Signal) benötigen eine zusätzliche Authentifizierung und Authorisierung seitens google, Freimaurer etc.
Du hast allerdings vollkommen recht, der Erste, der zu DIESEM Thema ein rundum ALLUMFASSENDES, LEICHT verständliches, SCHRITTWEISES Tutorial herausbringt, verdient sich krumm und dämlich - DAFÜR würden MASSEN an Entwicklern zahlen (überhaupt dann, wenn die Sache vonseiten der Webentwicklung aufgezäumt wird).
...darum geht's in meinem Usecase aber Gott-sei-Dank nicht - ein "Update", das durchgeführt wird, während die App gerade AKTIV läuft, können sich Server und Client zum Glück (noch?) ohne Einmischung des Plattformbetreibers untereinander ausmachen.
-
-
-
-