Ich versuche herauszufinden, wie man eine echte Websocket-App mit akka-http und akka-streams am besten implementiert. Wonach ich meistens suche, ist Einfachheit, die ich jetzt gerade nicht bekomme.
Angenommen, Sie haben eine recht komplexe Pipeline, die zwischen mehreren Anfragen unterscheiden muss und manchmal die Anfrage zur Verarbeitung an einen Akteur senden muss, manchmal eine Mongo-Abfrage und die Antwort zurückgibt, manchmal eine PUT für eine REST-API usw.
Im Gegensatz zu den einfachen Chat-Anwendungsbeispielen gibt es mindestens drei Probleme, die scheinbar keine Standardlösung haben:
Bedingt das Überspringen der Antwort, z. B. weil der Client nicht erwartet, dass diese Anfrage eine Antwort erhält. Wenn ich den typischen Fluss von Nachricht zu Nachricht benutze, muss ich, sobald die Anfrage ihr Ziel erreicht hat, verhindern, dass sie sich weiter zurück zum Websocket ausbreitet. Es kann mit einem speziellen Filter (beinhaltet etwas Schmerz) oder mit verschiedenen anderen Möglichkeiten (zB Überspringen Sie den Fluss konditionell mit akka-Streams ), aber das bringt eine Menge Standard und Komplexität mit sich. Im Idealfall möchte ich "Skip" -Nachrichten einfügen, die einfach alles andere überspringen.
Routing eingehender Nachrichten an den entsprechenden Ort (z. B. Schauspieler, Mongo). Wiederum kann ich Lösungen finden, die eine Menge Vortex beinhalten (z.B. Aussenden und Herausfiltern in Zweigen, die diese Art von Anfrage nicht behandeln). Idealerweise sollte ich in der Lage sein, folgendes zu definieren: Wenn die Nachricht X ist, sende sie dort, wenn die Nachricht Y ist, sende sie dort usw.
Fehler werden an den Client weitergeleitet. Sehr ähnlich dem oben beschriebenen Routing-Problem. Zum Beispiel, wenn die JSON-Analyse fehlschlägt, muss ich einen separaten Pfad hinzufügen (Broadcast + Merge), entlang dem ich eine Fehlermeldung sende, aber ich kann nicht einfach den gleichen Pfad wiederverwenden, wenn ein Fehler in der nächsten Stufe auftritt und ich will propagiere diesen Fehler an den Benutzer. Idealerweise sollte ich einen einzigen separaten Pfad für die Fehlerbehandlung haben, der an jedem beliebigen Punkt im Fluss verwendet werden kann, den Rest des Flusses vollständig umgeht und zurück zum Client geht.
Im Moment habe ich diesen wahnsinnig komplexen Graphen, der 15 Zeilen umfasst, mit Pfaden, die 20 verschiedene Stufen durchlaufen, und ich bin wirklich besorgt, die Komplexität dieser Lösung in Schach zu halten. Das DSL ist bei dieser Größe meist nicht lesbar. Ich könnte natürlich ein bisschen besser modularisieren, aber das fühlt sich wie eine wahnsinnige Menge an Ärger für etwas an, das viel einfacher sein sollte.
Vermisse ich etwas? Bin ich wahnsinnig, wenn ich Akka-Streams für solch eine Aufgabe in Betracht ziehe? Irgendwelche Ideen oder Codebeispiele, die es mir erlauben würden, all diese Komplexität in den Griff zu bekommen?
Vielen Dank im Voraus!
Dies ist eine sehr weitreichende Frage und kann in ihrer jetzigen Form nicht beantwortbar sein.
Akka HTTP behebt viele dieser Probleme in seinen HTTP-Handling-Layern (z. B. leere Antworten, Routing, Rückgabe von Fehlern). Könnten Sie einige der dort gelernten Lektionen anwenden und auf Ihr System anwenden? Oder, vielleicht besser, könnten Sie Ihr System von Websocket-Kommunikation in die Verwendung von HTTP-Kommunikation konvertieren und diesen Code direkt verwenden?
Tags und Links scala websocket akka modularity akka-stream