Gianluca T. wrote:
… in poche parole vorrei distribuire la mia applicazione su pi�
applicazioni (applicazione distribuita), ognuna delle quali si concentri
su una particolare problematica.
Mi spiego meglio, ammettiamo di avere una applicazione che gestisca
delle news/newsletter da esporre agli utenti di vari siti in area
pubblica e questi dati si possano anche amministrare in area riservata
mi troverei a gestire:
- Amministrazione news/newsletter
- Amministrazione clienti (1 cliente per ogni dominio)
- Amministrazione utenti/ruoli per ogni cliente/dominio
- Amministrazione security per dare accesso all’amministrazione di
news/newsletter ai relativi ruoli utente
Ora se faccio tutto in un unica applicazione questa diventa monolitica,
estremamente legata, sarebbe veramente una figata se si potesse creare:
- Applicazione di gestione news/newsletter (che gestisce solo le risorse
(intendo proprio resources rest) news/newsletter/categorie/tipi ecc. sul
db delle newsletter)
- Applicazione di gestione clienti (che gestisce solo le risorse
clienti/categorie/tipi ecc. sul db dei clienti)
- Applicazione di gestione sicurezza (che gestisce solo le risorse
utenti/ruoli/moduli applicativi con permessi-scadenze ecc. sul db dei
sicurezza)
Questo tipo di applicazioni in linea del tutto teorica sarebbe anche
fattibile crearle guardandole da un punto di vista di REST, quando poi
la risorsa news ha collegato un id cliente (customer_id) potrei mappare
con il client rest la risorsa che mi espone l’applicazione dei clienti
cos� da formare una suite di applicazioni che lavorano scambiandosi
risorse; mi rendo conto per� che cos� facendo a livello di model puro
(non rest) perderei completamente la possibilit� di fare cose carine
tipo belongs_to :customer oppure fare un News.find(:all, :include =>
:customer) per poter fare ricerche in cui la condizione la metto nella
tabella in join…; oltretutto mi rendo anche conto che cos� facendo
andrei incontro anche ad un problema non da poco: le transazioni
distribuite, urca non ci avevo pensato, si potrebbe risolvere il
problema lavorando con un solo db, ma allora se lavoro su un solo db
perch� non fare un’unica applicazione ?
Ho come l’impressione che questo tipo di visione da un lato sia
teoricamente possibile, dall’altro sia di difficile implementazione per
le ragioni sopra esposte…
Chiedevo quindi se qualcuno si è mai cimentato in uno sviluppo di questo
tipo…
Avere un controllo completo sul dominio del problema e’ fondamentale per
estrarne il meglio.
Partizionare il dominio comporta penalizzazioni alle prestazioni e alla
flessibilità .
Considera per esempio la tua idea di separare la gestione sicurezza in
un’altra applicazione.
La sicurezza e’ una funzionalita’ trasversale all’applicazione.
Praticamente ogni azione, prima di essere eseguita, richiede un
controllo di autorizzazione.
Non solo.
Spesso anche oggetti di view dipendono dalla sicurezza: pensa alle voci
di menu che vorresti visibili solo all’amministratore, per fare un
esempio.
Puoi permetterti di accedere via web al gestore di sicurezza una o piu’
volte ad ogni azione?
Talora invece ci possono essere altre esigenze e REST ci permette
qualcosa altrimenti molto piu’ difficile.
Ti accenno ad una mia esperienza.
La nostra applicazione doveva gestire contatti, e piuttosto che
implementare ex-novo la gestione contatti, abbiamo preferito utilizzare
le API REST di Highrise (http://www.highrisehq.com).
I tempi di sviluppo si sono ridotti notevolmente, ma abbiamo sacrificato
una buona fetta di prestazioni, sia perchè devi andare sulla rete a
prendere dati, sia perchè rinunci a tutte le ottimizzazioni che il
database permette per reccogliere dati relazionati.
Se hai una porzione della tua applicazione che vedi come una componente
verticale “isolabile” (low coupling, high cohesion) puoi considerare
l’approccio external-REST, ma solo se ti porta grandi benefici.
Se hai controllo sul codice, l’approccio migliore e’ sicuramente quello
dei plugin.
Anche se forse Rails non ha una gestione di componenti all’altezza di
Django (Python) o Seaside (Smalltalk), si possono ottenere elevati
livelli di riusabilita’.
