Real Time WebSocket

di il
6 risposte

Real Time WebSocket

Ma se il mio Client usa Retrofit per recuperare i dati da MongoDb attraverso REST. Per renderlo RealTime, devo aprire un canale con WebSocket?

Ora qui mi sorge un dubbio di implementazione. Se da Client1 faccio una push di un oggetto, e listen di Client2 lo riceve. Come posso fare push su MongoDB? o ad ogni nuovo push di oggetto, devo metterci riga sotto una POST?

sono confuso.


Ma per utilizzare REST quasi in maniera Real Time, visto che trovo comodi i suoi verbi che sono molto più semplici, non è possibile mettere un ciclo di tempo di 1000ms in cui fa una GET sugli elementi? Andrei incontro al solo problema di RAM no?

6 Risposte

  • Re: Real Time WebSocket

    Stai facendo un polpettone di teconologie che non centrano niente una con l'altra!

    1) Retrofit: libreria per create servizi REST da una parte e consumarli dall'altra. Stessa robba di jersey ed n-mila altre librerie simili. (TECONOLOGIA 1)
    2) Mongodb: database documentale, che si interroga via servizio REST (da cui l'uso di Retrofit), ma che con Retrofit non centra una cippa (TECONOLOGIA 2)
    3) Websocket: sistema di invio messaggi in push su protocollo HTTP, che non centra una cippa con Retrofit O Mongodb (TECONOLOGIA 3). Al momento Retrofit NEMMENO SUPPORTA il protocollo Websocket!!!! Al limite lo usi per PARSARE il messoggio che e' stato serializzato in formato JSON.

    Poi, come sono stati combinati e' tutta un'altra storia, MA c'e' di mezzo del codice che li fa parlare tra di loro!

    Hai ragione ad essere confuso
  • Re: Real Time WebSocket

    HalJordan ha scritto:


    Ma se il mio Client usa Retrofit per recuperare i dati da MongoDb attraverso REST. Per renderlo RealTime, devo aprire un canale con WebSocket?

    Ora qui mi sorge un dubbio di implementazione. Se da Client1 faccio una push di un oggetto, e listen di Client2 lo riceve. Come posso fare push su MongoDB? o ad ogni nuovo push di oggetto, devo metterci riga sotto una POST?
    Allora: innanzitutto REST non ha nulla a che fare, di per sé, con WebSocket. REST è uno "stile architetturale" e si usa tipicamente/principalmente su HTTP perché HTTP offre "verbi", header, status code, ecc... che lo rendono un protocollo "applicativo".
    WebSocket invece permette solo di mantenere attiva una comunicazione full-duplex tra client e server, ovvero ANCHE il server può inviare al client qualcosa QUANDO vuole. E questo permette ad esempio di evitare meccanismi di "polling" che il client altrimenti dovrebbe fare ogni tot di tempo.
    Poi cosa viene scambiato su WebSocket è assolutamente a libera scelta, potrebbero essere semplici stringhe, dati JSON, blocchi di dati binari, ecc...

    Se la questione è: un ClientY deve aggiornarsi (per ricevere dati modificati da un altro ClientX) SENZA fare polling, allora lo scenario potrebbe essere: il canale WebSocket può servire affinché il server dica sostanzialmente al ClientY "hey, aggiornati!" e il ClientY allora fa una request in stile REST per ricevere la risorsa aggiornata. Tutto qui ..
  • Re: Real Time WebSocket

    Scusami perchè polpettone? forse da come l'ho spiegata sicuramente. Ma anche come tu sottolinei, Retrofit(Android) -> Server(Node.jS) -> Express -> Mongoose -> MongoDB.

    La mia domanda è, come rendo l'applicazione Android Real Time. Facendo una ricerca veloce o uso Socket.io o Firebase RealTime Database. Il secondo caso è una scelta implementativa esterna dal mio Server.
    Quindi la mia domanda è sui Socket. Visto che il canale aperto tra due client lo rende RealTime, come faccio poi a conservare i messaggi che si inviano i due client in un database
    Cioè a me interessa che non sia io a fare una GET, ma che il sistema sia bidirezionale. O come ho scritto alla fine, l'unica soluzione è interrogare il server tramite TimerTask, che ad ogni tot ms compie una GET.

    Grazie migliorabile per la risposta

    P.s. per renderlo più chiaro, forse mi sto perdendo io in qualcosa, sto parlando di una Chat Application, del tipo Whatsapp.
  • Re: Real Time WebSocket

    andbin ha scritto:


    HalJordan ha scritto:


    Ma se il mio Client usa Retrofit per recuperare i dati da MongoDb attraverso REST. Per renderlo RealTime, devo aprire un canale con WebSocket?

    Ora qui mi sorge un dubbio di implementazione. Se da Client1 faccio una push di un oggetto, e listen di Client2 lo riceve. Come posso fare push su MongoDB? o ad ogni nuovo push di oggetto, devo metterci riga sotto una POST?
    Allora: innanzitutto REST non ha nulla a che fare, di per sé, con WebSocket. REST è uno "stile architetturale" e si usa tipicamente/principalmente su HTTP perché HTTP offre "verbi", header, status code, ecc... che lo rendono un protocollo "applicativo".
    WebSocket invece permette solo di mantenere attiva una comunicazione full-duplex tra client e server, ovvero ANCHE il server può inviare al client qualcosa QUANDO vuole. E questo permette ad esempio di evitare meccanismi di "polling" che il client altrimenti dovrebbe fare ogni tot di tempo.
    Poi cosa viene scambiato su WebSocket è assolutamente a libera scelta, potrebbero essere semplici stringhe, dati JSON, blocchi di dati binari, ecc...

    Se la questione è: un ClientY deve aggiornarsi (per ricevere dati modificati da un altro ClientX) SENZA fare polling, allora lo scenario potrebbe essere: il canale WebSocket può servire affinché il server dica sostanzialmente al ClientY "hey, aggiornati!" e il ClientY allora fa una request in stile REST per ricevere la risorsa aggiornata. Tutto qui ..
    Voglio salvare i dati nel Database e avere un modo per aggiornare i Client in automatico, senza che facciano GET da soli. Se ci metto un timer per update, occupo RAM e consumo batteria(vabbè in questo caso è esagerato, però non è la soluzione ottimale)
  • Re: Real Time WebSocket

    HalJordan ha scritto:


    Voglio salvare i dati nel Database e avere un modo per aggiornare i Client in automatico, senza che facciano GET da soli.
    E questo puoi ANCHE farlo tramite WebSocket, non è certo proibito o un grosso problema. Ma non c'entra con il database (sul server), nel senso che ovviamente il server dovrà ricevere i dati da A, memorizzarli su db e poi notificare B, C, D, ecc...

    A questo punto chiaramente REST non c'entra più tanto, cioè COSA il server invia al/i client tramite WebSocket lo decidi tu. Potrebbe essere un JSON che descrive in generale la modifica e contiene anche il/i dato/i. Non so ... ovviamente è tutto da studiare.
  • Re: Real Time WebSocket

    andbin ha scritto:


    HalJordan ha scritto:


    Voglio salvare i dati nel Database e avere un modo per aggiornare i Client in automatico, senza che facciano GET da soli.
    E questo puoi ANCHE farlo tramite WebSocket, non è certo proibito o un grosso problema. Ma non c'entra con il database (sul server), nel senso che ovviamente il server dovrà ricevere i dati da A, memorizzarli su db e poi notificare B, C, D, ecc...

    A questo punto chiaramente REST non c'entra più tanto, cioè COSA in server invia al/i client tramite WebSocket lo decidi tu. Potrebbe essere un JSON che descrive in generale la modifica e contiene anche il/i dato/i. Non so ... ovviamente è tutto da studiare.
    Dovrei studiarmi bene l'implementazione, perchè comunque dovrei toccare ambo i lati e non so se ho tempo per riscrivere il tutto.
    Però se dovessi scegliere questa implementazione di fare una GET sul client ogni tot ms, potrebbe essere considerato una applicazione Real Time, ma non ottimale giusto?

    Sono sincero, è il lavoro di tesi che dovrei consegnare. Stavo usando Firebase per il lato messaggistica(mentre le altre funzionalità uso il Server implementato con Stack MEAN), ma mi sembra una scelta così banale, che non vorrei poi che la commissione mi faccia notare la pochezza della scelta implementativa. Quindi ho deciso di portare tutto su server locale e utilizzare i verbi di rest per acquisire le informazioni.
Devi accedere o registrarti per scrivere nel forum
6 risposte