Best practice per la strutturazione di un'applicazione "grandi" Rails

Question

La mia domanda qui è la ricerca delle migliori pratiche, consigli generali e intuizioni, piuttosto che una soluzione a un problema specifico.

Sono nelle prime fasi della pianificazione di un progetto Rails che considero piuttosto ampio. Al suo livello più semplice offre un CMS cookie-cutter agli utenti target. Quindi gli utenti si registrano e scelgono un sottodominio e ricevono un sito Web piuttosto semplice con CMS.

Pertanto l'intera applicazione è di circa 4 '' lati diversi ad esso:

• Un sito di vendita di vendita del prodotto per gli utenti finali - www.myapp.com
• Un area di amministrazione centrale, dove il personale può accedere in e gestire gli account ecc - www.myapp.com/superadmin
• degli utenti propri siti web - subdomain.myapp.com
• Gli utenti area di amministrazione/CMS - subdomain.myapp.com/admin

Quindi quello che sto cercando è la migliore pratica per strutturare l'app. cioè dovrebbe essere inserito in un'unica enorme applicazione o dovrebbe essere diviso in 2 (o più) app più piccole?

Se distribuito come un'unica applicazione, è possibile visualizzare i problemi relativi al routing sia come sito Web di vendita sia come sito Web degli utenti per un set di percorsi radice, inoltre non vorrei che i percorsi impostati per il sito Web di vendita fossero accessibili tramite il siti web degli utenti. Qualche cosa può essere fatto sia all'interno di Rails o a livello di Apache (riscrittura mod?) Per garantire che non vi sia alcun mix di percorsi?

Se suddiviso su 2 o più applicazioni, come si ottengono le applicazioni che condividono lo stesso database? E 'anche una buona idea? Ci sono dei benefici dal dividere l'applicazione (come isolare i problemi in una zona dell'app, piuttosto che portare tutto giù)?

Mi rendo conto che questo post solleva alcune domande diverse, ma apprezzo qualsiasi consiglio e opinione che tu possa darmi.

Answer 1

Bene, dato che nessun altro ha parlato, ti incoraggio a leggere un po 'sull'architettura orientata ai servizi. Il libro Enterprise Rails di Dan Chak ha un grande materiale su questo, e puoi leggerne molte attraverso Google Libri. Prova il capitolo 13, here. Penso che ti metterà sulla strada giusta.

Answer 2

Credo che i vantaggi di isolare le vostre preoccupazioni in app separate superino i costi. Probabilmente comincerei con solo 2 app (una per il sito principale e superadmin, una per i siti client e gli amministratori), l'accesso allo stesso database, ma si potrebbe fare 4.

Lo svantaggio è che non si davvero avere isolamento dal momento che tutte le tue app sono legate a un database. Alla fine ti imbatterai in problemi di scalabilità con il tuo database, ma l'avvio semplice con un database ti consentirà di iniziare. Una strategia per il ridimensionamento in un secondo momento consiste nell'aggiungere un db slave che viene utilizzato dal sito client e dalle app del sito principale, mentre le app di amministrazione utilizzano il db principale. Questo insieme a un TON di cache ti porterà molto lontano.

Non c'è niente di sbagliato nell'avere accesso a più db di applicazioni su un db, tuttavia è necessario un modo per condividere codice comune tra le tue app. I tuoi modelli per la maggior parte. L'ho già fatto gettando tutti i miei modelli in un plugin che condivido come sotto-modulo in git o come esterno in svn. Avere app separate renderà ogni app più piccola e più facile da mantenere.

Tuttavia, dove mantieni le tue migrazioni?Dove metti alla prova i tuoi modelli? Opterei per l'app superadmin. Inoltre, apporti una modifica a un modello o allo schema e ora devi controllare le 2-4 app e assicurarti che funzionino ancora!

Migliore isolamento, comunicazioni separate di db e inter-app tramite web API (SOA) e non devi preoccuparti di questo. SOA Penso che sia la strada da percorrere dopo un certo punto, ma SOA potrebbe essere prematuro quando si inizia per la prima volta.

In ogni caso, avere app separate ti imposta per SOA ma non devi saltare oltre un singolo db per iniziare.

Answer 3

Il problema maggiore che vedo separando in diverse app è la perdita di flessibilità. Cosa succede se, in futuro, un'attività precedentemente amministrativa (ad esempio il caricamento di un tipo di file) diventa un "compito utente"? Dovresti spostare il codice da un'applicazione all'altra.

Manterò tutto su una singola applicazione e utilizzo i ruoli per filtrare ciò che ogni utente può vedere e fare. Potrebbe essere un po 'più difficile all'inizio, ma si paga nel prossimo futuro.

Dai un'occhiata ai framework di autorizzazione, come declarative_authorization o cancan.

Answer 4

Vedo che il tipo di problema che stai affrontando è, cercando di costruire un'applicazione che avrà vari sottodomini, quindi account_manager un plugin può risolvere il tuo problema.

anche se la tua applicazione è abbastanza grande da mantenere che dividerli in due o tre sarebbe una buona idea, con risorse restfull puoi far dialogare le tue applicazioni e così via.

mentre se stai pensando di averli sotto un unico database, questo è abbastanza semplice in rail usando la connessione_stab.

Penso che si possa dividere l'applicazione in tre o quattro diverse applicazioni in cui il set di cluster gestirà ogni richiesta di applicazioni, quindi la velocità sarà buona. inoltre puoi raggruppare funzionalità simili in un'unica app per assicurarti che la loro manutenzione sia semplice.

http://www.railslodge.com/plugins/1113-subdomain-fu

Answer 5

avrei impacchettare tutto questo nella stessa app perché non sarà duplicare le classi (modelli, plugin, ecc) in tutte le applicazioni. Inoltre: l'esecuzione di 4 app significa che avrete 4 processi che consumano memoria a causa dei 4 stack Rails separati che hanno caricato.

Compilandolo in un'applicazione elimina il problema. Per il problema tra il sito di vendita e il sito degli utenti che devono avere radici diverse che possono essere risolti, as mentioned earlier, per subdomain_fu. Lasciate che vi spieghi con alcuni esempi di codice da un'applicazione che ho:

map.with_options :conditions => {:subdomain => 'logs'} do |admin| 
    admin.resources :channels do |channel| 
    channel.resources :logs 
    end 
    map.root :channels 
    map.connect ':id', :controller => "channels", :action => "show" 
end 

Come si vede qui, il :conditions per il metodo with_options imposta :subdomain essere logs che significa che qualsiasi cosa in arrivo per logs.mysite.com riempirà queste condizioni e quindi sarà indirizzato in questo modo.

Ora più avanti in questo file di routing ho tutto il resto avvolto in un blocco simile:

map.with_options :conditions => {:subdomain => nil} do |admin| 
    # shebang! 
end 

tutto ciò che accade a mysite.com andrà a queste rotte.

Infine, la compilazione di tutto in una mega-super-iper-app eliminerà i problemi di condivisione del database.

Answer 6

Per quanto riguarda la mia ricerca, la maggior parte delle aziende su vasta scala opterebbe per SOA con più database. Ecco i link ad alcune informazioni su come Linked In e EBay pensare a questo. E per fare eco a PreciousBodilyFluids, consiglio vivamente il libro Enterprise Rails di Dan Chak.