2014-04-25 15 views
10

Sto lottando con alcune scelte architettoniche per un'applicazione scalabile di Internet of Things.Strutture Web/componenti aggiuntivi di ordine superiore per Twisted/Cyclone/Tornado (accesso Web/utente/amministratore)?

Ho scelto di basare il mio progetto su Twisted aumentata con il quadro Cyclone di fornire molti Tornado convenances (WebSockets, autor-decoratori, sicuri-biscotti, ecc)

Utilizzando un nucleo intrecciato ha lavorato splendidamente per me . Ho numerosi protocolli IP e interfacce hardware che si sono rivelate tutte dotate di un ottimo supporto per le librerie all'interno di twisted (e l'aggiunta di nuovi protocolli e interfacce alla mia applicazione sono gli angoli più probabili che avrò lo scorrimento del progetto), tutto con Twisted che richiede CPU molto bassa e conteggi di connessione molto elevati.

I miei problemi sono con la funzionalità webapp di secondo ordine.

Ho inserito Cyclone pensando che con i suoi privilegi di autenticazione (OpenID, oauth, user-auth decorator e secure-cookies) non ci sarebbe voluto molto per implementare la funzionalità utente/sessione/admin nella mia webapp. Dopo le oltre 500 linee di astrazione mio database (tramite txmongo) e solo accessi utente edificio è diventato chiaro che sia:

  1. non ho capito quanto poco Cyclone/Tornado portare nel/session/spazio utente admin e
  2. non ha capito la quantità di codice necessario per colmare le lacune se il vostro cercando di costruire una webapp autenticazione multi-utente

un amico mi ha segnalato a Flask, che inizialmente ho pensato che era completamente ridondante, fino a quando ho trovato flask plugins. La combinazione di Flask-Login e Flask-Admin coprirà completamente le mie esigenze di utente, sessione e utente-amministratore, impedendomi di scrivere ciò che immagino essere circa 2k di codice di codice. Sfortunatamente, i plugin dei flask sono tutti pieni di codice di blocco e chiamate alle librerie di blocco. Non li vedo come compatibili con il mio progetto anche se vengono utilizzati WSGIcontainers dato che la funzionalità utente/sessione si verifica con ogni caricamento di pagina (inoltre non vedo alcuna scorciatoia che mi permetta di portarli in un mondo asincrono senza lavorare o meno uguale a quello di loro)

la mia domanda è la riscrittura:

nello spazio python asincrona (... speriamo nello spazio Contorto, date le mie esigenze di protocollo), ci sono plugin o strutture alternative che fornire funzionalità di utente/accesso/amministratore pronte all'uso simili a quelle presenti in Flask-Login e Flask-Admin?

P.S. Ho visto Klein come l'ovvia versione Twisted di Flask, ma non sembra avere un ecosistema di plugin, e non trovo nessun utente/sessione/amministratore forte lì.

P.P.S. Quando scrissi questa domanda, avevo già scritto il mio (crappy) sistema user-login-session. Quindi quello che sto cercando è la funzionalità "Admin" (funzioni CRUD automatizzate su record in stile utente, incluso il rendering dell'interfaccia utente Web, tutte progettate in modalità Twisted/async). Ho chiesto all'utente/login nella domanda nel caso in cui risultasse che esiste una soluzione già integrata (come flask-login e flask-admin), nel qual caso lascerei volentieri il mio codice e passerò a quello.

+3

Ci sono alcune persone là fuori che hanno provato ad aggiungere il supporto di sessione a Tornado, anche se sembrano non essere più mantenute: https://github.com/milancermak/tornado, https://github.com/diogobaeder/pycket. Non ho usato neanche così non sono sicuro della loro qualità. Potresti essere in grado di prendere in prestito del codice, almeno. – dano

+0

flask-socketio ha il supporto asincrono. guarda questo: http://flask-socketio.readthedocs.org/en/latest/ – chfw

+0

Non hai davvero bisogno che l'amministratore sia completamente asincrono, giusto? In tal caso, è possibile utilizzare Flask-Admin in una WSGIResource ritorta. Per quanto riguarda la sessione, sono venuto qui cercando la stessa risposta :) – dpn

risposta

2

Hai davvero bisogno di tutto asincrono? Prendi in considerazione WebSocket asincroni ma sincronizza i rendering delle pagine. Se è necessario, aggiungere un proxy downstream asincrono o un servizio di bilanciamento del carico che eliminerà virtualmente l'overhead dell'IO del server dell'app.

Problemi correlati