2017-06-20 3 views
0

Ich werde Rails API erstellen, die WebSocket basierend auf ActionCable behandelt (vor allem ist es sinnvoll, ActionCable im API-Modus zu verwenden?). ActionCable funktioniert gut für die Vollstack-Rails-Anwendung, aber ich stieß auf Schwierigkeiten mit der API. Die erste Frage ist, welche Art von Format alle Anfragen an actionCable Server haben sollte. Alles, was ich bisher gefunden habe, ist abonnieren Aktion:Rails ActionCable API-Modus

{ 
    "command":"subscribe", 
    "identifier":"{\"channel\":\"SomeChannel\"}" 
} 

Wie wäre es mit anderen? Gibt es Unterlagen, wo ich das finden kann?

Vielen Dank im Voraus

+0

Ich würde den Ziel-Client auch betrachten. Ich weiß nicht, ob ActionCable nicht-Browser-Clients hat und es möglich ist, dass die Websocket-API auch für native mobile Apps (nicht nur Browser) zugänglich sein soll ....? P.S. Ich bin voreingenommen, da ich der Autor von Jod (der Ruby-Web-Socket-Server) und von [Plezi] (http://www.plezi.io) bin (ein Echtzeit-Anwendungs-Framework, das auf Jod basiert). Ich habe mit meinen Aktionen dafür gestimmt, dass Webcasts Hände von ActionCable lassen. – Myst

+0

Ja, mein Hauptziel ist es, nur Handys zu behandeln, und ich frage mich, ob ActionCable dazu geeignet ist. – mike927

Antwort

0

Ich würde wahrscheinlich vermeiden, dass die ActionCable Semantik und internes Protokoll für ein API-Projekt verwenden, das Nicht-Browser-Clients enthält.

Zum Beispiel:

  • ActionCable interne Semantik/Protokoll kann zwischen den Versionen ändern. Da Ihr Code eng mit den internen Funktionen von ActionCable gekoppelt ist, kann es schwieriger sein, ein Upgrade durchzuführen.

  • Die interne Semantik/das Protokoll von ActionCable enthält möglicherweise alles, was Sie benötigen, während das Schreiben Ihres eigenen Websocket-Nachrichtenprotokolls (besonders mit JSON) sehr einfach ist und Ihnen eine genaue Anpassung bietet.

Das bedeutet nicht, dass Sie sich komplett von Rails entfernen müssen. Es sollte einfach genug sein, Ihre Rails-Modelle und -Code innerhalb einer Nicht-Rails-Websocket-Alternative zu verwenden.

Auch Ruby hat einige schöne Websocket Alternativen für ActionCable.

ich bin voreingenommen, wobei der Autor sowohl von Iodine - an HTTP/Websocket server with native Pub/Sub und Plezi.io, a real-time web application framework ... aber ich würde wahrscheinlich Jod verwenden (mit oder ohne den zusätzlichen Komfort von Plezi angeboten).

Eine einfache Websocket Anwendung mit Plezi wird wie folgt aussehen (ernsthaft, führen Sie den folgenden Code aus dem Terminal irb, es funktioniert):

require 'plezi' 
class ChatServer 
    def index 
    "Use Websockets to connect." 
    end 
    def on_open 
    @name = params['id'] || "anonymmous" 
    subscribe channel: "chat" 
    publish channel: "chat", message: "#{@name} joind the chat." 
    write "Welcome, #{@name}!" 
    end 
    def on_close 
    publish channel: "chat", message: "#{@name} left the chat." 
    end 
    def on_message data 
    publish channel: "chat", message: "#{@name}: #{data}" 
    end 
    def on_shutdown 
    write "Server shutting down. Goodbye #{@name}" 
    end 
end 
Plezi.route '/', ChatServer 

# We'll monitor message just for kicks: 
subscription = Iodine.subscribe(pattern: "*") do |channel, message| 
    # print a log? 
    puts "\n* Message on channel #{channel}:\n#{message}\n" 
end 
# make sure we don't duplicate our monitoring on every process. 
root_pid = Process.pid 
Iodine.run { Iodine.unsubscribe(subscription) unless Process.pid == root_pid } 

exit 

Kein Redis Server erforderlich ist, keine besonderen Dinge vorzubereiten und Es ist möglich, PLEZI als Middleware innerhalb einer Rails-Anwendung zu verwenden (mit dem iodine Server anstelle von puma).