2016-07-05 30 views
8

Ich versuche herauszufinden, die beste Möglichkeit, eine echte Websocket-App mit akka-http und akka-Streams zu implementieren. Wonach ich meistens suche, ist Einfachheit, die ich jetzt gerade nicht bekomme.Akka Streams Websocket Wiring

Angenommen, Sie haben eine ziemlich komplexe Pipeline, die zwischen mehreren Anfragen unterscheiden muss und manchmal die Anfrage zur Verarbeitung an einen Akteur senden, manchmal eine Mongo-Abfrage ausgeben und die Antwort zurückgeben, manchmal eine PUT auf einer REST-API ausführen usw.

im Gegensatz zu den einfachen Chat-Anwendung Beispiele gibt, gibt es mindestens drei Probleme, die, die keine Standardlösung scheinen ergeben haben:

  • die Antwort wahl Skipping, zum Beispiel weil sie nicht durch zu erwarten ist Der Client, der diese Anfrage erhält, wird eine Antwort erhalten. 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 (mit etwas Schmerz verbunden sein) oder unter Verwendung verschiedener anderer Arten (z. B. Conditionally skip flow using akka streams) durchgeführt werden, aber dies fügt eine Menge Standard und Komplexität hinzu. Idealerweise würde ich gerne "Skip" -Nachrichten einfügen, die einfach alles andere überspringen.

  • Routing eingehender Nachrichten an die entsprechende Stelle (z. B. Schauspieler, Mongo). Wiederum kann ich Lösungen finden, die eine Menge Vortex beinhalten (z. B. Aussenden und Herausfiltern an Zweigen, die diese Art von Anfrage nicht behandeln). Im Idealfall sollte ich in der Lage sein, etwas wie zu definieren: Wenn die Nachricht X ist, sende sie dort, wenn die Nachricht Y ist, sende sie dorthin, usw.

  • Fehler an den Client zurückgeben. 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 diese irrsinnig komplexen Graphen 15 Zeilen mit Pfaden Spanning> 20 verschiedenen Stufen durchlaufen und ich bin wirklich besorgt über 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.

Fehle 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!

Antwort

2

Dies ist eine sehr weit reichende Frage und kann in ihrer gegenwärtigen Form nicht beantwortbar sein.

Akka HTTP adressiert 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 umwandeln und diesen Code direkt verwenden?