interazione Rails / Node.js

Question

interazione Rails / Node.js

#1 da (0 voti)
#2 da (0 voti)

0

Io e il mio collega di lavoro stiamo sviluppando un'applicazione web con rails e node.js e non possiamo raggiungere un consenso in merito a una particolare decisione architettonica.

La nostra configurazione è fondamentalmente un server di rail che funziona con node.js e redis, quando un client effettua una richiesta http alla nostra API rails in alcuni casi la nostra applicazione rails invia la risposta a un database redis e quindi node.js trasmette la risposta via websocket.

Il nostro disaccordo si verifica nel seguente punto: il mio collega pensa che l'uso di node.js per inviare dati ai client sia in qualche modo logico e dovrebbe essere all'interno del modello, quindi nel primo codice che ha scritto ha usato i comandi di broadcast in callback e altri luoghi del modello, è convinto che i modelli siano il posto migliore per l'interazione tra rotaie e nodi.

Io d'altra parte penso che l'uso di node.js appartenga al runtime reame, il mio intento è che i comandi di broadcast e altre interazioni node.js dovrebbero essere nel controller e dovrebbero essere usati in un modello solo se passati attraverso un un'interfaccia ben definita, proprio come la situazione in cui un modello deve accedere all'utente corrente di una sessione.

A questo punto siamo stanchi di discutere su questa stessa cosa e la nostra discussione consiste nel ripeterci ripetutamente le nostre stesse opinioni. Qualcuno, preferibilmente con esperienza nello stesso setup, può darci una risposta univoca dicendo quale soluzione è più adeguata e perché è?

architecture ruby-on-rails node.js system

posta lpvn 15.10.2013 - 15:14

fonte

2 risposte

0

In realtà (senza conoscere più dettagli della tua architettura o del tuo dominio), questa situazione sarebbe perfetta per un oggetto di servizio --- come un oggetto mediatore occasionale tra il controller e i tuoi modelli.

Chiamalo WebSocketsService o BroadcastService, o quello che ti pare. Rendilo un singleton (o usando la roba Ruby singleton in lib di std, o forse un modulo estendendosi con alcuni metodi appiccicati su di esso), e accedendo dal controller o da un modello.

Il tuo controller potrebbe invocarlo:

WebSocketsService.broadcast(my_model, "this message!")

... e allo stesso modo per i tuoi modelli. Hai menzionato sopra la possibilità di passare attraverso una "interfaccia ben definita": qualcosa di simile potrebbe essere.

module WebSocketsService
  extend self

  def broadcast(model, message)
    ## interact with Node here...
  end

end

Se decidi di passare a una soluzione solo su Rails in futuro, l'unica cosa che dovrai cambiare è l'implementazione all'interno di questi metodi. Né i controllori né i modelli coinvolti avrebbero bisogno di sapere.

Ho appena aggiunto una directory / services all'interno di / app per tenerli tutti.

Solo un'idea che non avevo mai visto prima.

risposta data 16.10.2013 - 23:15

fonte

Leggi altre domande sui tag architecture ruby-on-rails node.js system

Buffer con dimensioni fisse o buffer variabili con socket C # Come rendere noto il mio progetto open source? [duplicare]

score 0 · Accepted Answer

Vedendo i tuoi chiarimenti e visto che vuoi le opinioni degli sviluppatori, ecco il mio $ 0.02. Chiamerei Announce dai controller, per due motivi. Innanzitutto, tendo a vedere i callback di ActiveRecord come una sorta di chiamata "implicita" / "passiva" di un'azione. ActiveRecord assicura di eseguire tali callback per te e, a meno che non si interrompano, non ti presti molta attenzione. Non devi chiamarli manualmente; tendono a questioni minori e di routine.

Questa ipotesi di lavoro che ho sempre avuto mi porta alla seconda ragione per me: restituire una risposta lato client è un processo "attivo", in tempo reale, e dai diritti dovrebbe essere qualcosa di esplicitamente invocato e visibile nei più "attivi" lato della base di codice (cioè, i controllori). Restituire le risposte a un browser (tramite Rails, Node, & c.) È più responsabilità di un controller e il framework Rails è orientato verso questo tipo di configurazione.