Architettura di app con due interfacce indipendenti (web, touch screen)

Naviga le tue risposte
2

Ho intenzione di costruire un dispositivo basato su raspberry pi che legge i dati dal bus del sensore (porta seriale), lo analizza e lo presenta sul touch screen. Il touch screen verrà utilizzato anche per la configurazione. Il dispositivo deve avere un'interfaccia web con uguale funzionalità.

Quello che sto progettando di fare è dividere l'applicazione per 2 o 3 applicazioni separate (python) con database come supporto per lo scambio di dati. Flask basato per interfaccia web e basato su Kivy per touch screen. Per non scegliere quale sarà il "master" che legge il bus del sensore, sto pensando di introdurre un terzo (senza testa) che sta svolgendo il lavoro principale: acquisire dati, analizzare, produrre eventi e archiviarli in un database (MongoDB o MySQL).

Teoricamente tutti i framework potrebbero lavorare in un programma in thread separati con spazio dati comune, ma sembra essere meno elastico e più difficile da mantenere e aggiungere altre interfacce (ad esempio un altro bus seriale per parlare con altri dispositivi) senza menzionare l'integrazione con nginx.

È giusto approccio?

    
posta d21d3q 09.01.2017 - 23:48
fonte

1 risposta

2

Il tuo approccio va bene, in questo caso, "divide et impera", secondo me è l'approccio migliore quando si affrontano input e output diversi.

lo progetterei in questo modo:

Un'unica app per fungere da API e il "cervello" per le altre app che raccolgono solo input.
lascerei la responsabilità di visualizzare le informazioni su una pagina Web o / e sullo schermo tattile con l'app API (app delle fiaschette).

Avere il codice touch screen nell'app pallone. e dopo aver fatto, vedi se è una buona idea separarlo. poiché verrà eseguito con un thread diverso, il codice verrà scritto in un modo che consentirà una separazione ragionevolmente facile in seguito.

l'unico problema che vedo è il Database come mezzo di comunicazione.

  1. tutte le tue applicazioni dipenderanno dal database per comunicare, caricheranno il DB, che dovrai tenere in considerazione.
    anche il blocco del DB deve essere preso in considerazione, poiché è possibile scrivere nello stesso posto da fonti diverse.

    2. Il database

  2. diventerà un singolo punto di errore - DB down o broken == > nessuna app.

  3. è anche più difficile ridimensionare o distribuire l'app con una dipendenza DB.
  4. persisterà i dati che non hanno bisogno di persistenza come l'input seriale. dopo un po 'il tuo DB sarà enorme a meno che non lo pulisci

L'utilizzo di un DB come mezzo per comunicare tra app non è generalmente una buona idea. per i dati persistenti della tua app API di flask puoi conservare un database, ma non per la comunicazione.

Vedo due opzioni per la comunicazione tra i tuoi servizi / app

  1. è sufficiente disporre dell'agente (input seriale) per richiamare gli endpoint nell'API RESTful. e a sua volta farà la sua magia e visualizzerà le informazioni su web e touch screen

  2. messaggio / coda forse usando redis o rabbitmq . mi piace lonstar suggerito. ma è più complesso e forse eccessivo per le tue esigenze

risposta data 13.01.2017 - 11:06
fonte

Leggi altre domande sui tag

In relazione al design e al runtime - è meglio parallelizzare le sotto-attività più piccole o le attività in bundle? DAO orientato a CRUD multipli, ma richiede una sorta di join di dati di grandi dimensioni