AngularJS Multi Tenancy

Question

Sto lavorando a un piccolo team che progetta un sistema di gestione dei processi per essere utilizzato da diversi clienti all'interno dello stesso settore. L'obiettivo del sistema e i requisiti di alto livello tra i clienti sono molto simili. Tuttavia, come previsto, una volta che abbiamo iniziato a scavare più a fondo nelle loro esigenze individuali, abbiamo ottenuto una personalizzazione piuttosto ampia richiesta per ogni singolo cliente coinvolgendo praticamente tutto, inclusi dati, moduli di input, convalida, flusso di lavoro, reporting ecc.

Aggiungere tutto questo ci siamo resi conto che un'architettura multi-tenant sarebbe probabilmente l'approccio migliore per farlo accadere. Il backend è molto oltre la progettazione ed è un RESTful api in .net in fase di creazione con ServiceStack, RavenDB e Sql Server. Chiunque abbia familiarità con ServiceStack saprà che è estremamente flessibile e costruito con la capacità di innestare la mente - questo ha reso l'implementazione di un'API REST multi-tenant molto più semplice di quanto ci aspettassimo. Stiamo utilizzando una convenzione molto semplice per identificare e autorizzare gli inquilini controllando un valore nella sessione che appartiene a ciascuna richiesta (tutte le richieste "specifiche del tenant" devono essere autenticate in modo che sia sempre disponibile una sessione). Quindi attualmente non c'è quasi nessuna necessità di tenere traccia o passare un id titolare dal client in qualsiasi URL di percorso. Pertanto, per l'API di back-end, abbiamo raggiunto l'obiettivo di progettare un singolo codice base che supporti clienti diversi con una buona quantità di riutilizzo del codice e flessibilità per personalizzare/estendere le funzionalità specifiche del tenant secondo necessità.

Quindi, con il backend in gran parte distanziato, abbiamo rivolto la nostra attenzione al frontend in cui ci stiamo davvero sforzando di implementare un approccio multi-tenant simile in AngularJS. Parte del problema è il fatto che siamo relativamente nuovi a livello angolare. Abbiamo un po 'di esperienza nella creazione di app monouso usando lo "schema di cartelle" standard, ma quando guardiamo ai nostri requisiti multi-tenant qui stiamo davvero lottando per legare tutto insieme (struttura generale del progetto/percorsi/viste) per supportare lo stesso multi - obiettivi di progettazione persistenti in AngularJS che abbiamo raggiunto con il backend (base di codice singolo che supporta il riutilizzo, flessibilità & personalizzazione). Lo module pattern sembra una grande opzione per "inserire" le funzionalità personalizzate per titolare, ma la cosa più importante che ci manca ancora è un approccio generale all'architettura che ci fornisce un singolo codice base AngularJS che supporti gli obiettivi menzionati sopra. I professionisti di AngularJS possono aiutarci a superare la gobba e raccomandare un approccio qui?

Grazie!

Answer 1

Questa è una domanda di design quindi la mia risposta sarà di alto livello.

Un'applicazione Web lato client multi-tenant avrà le seguenti variabili, la maggior parte delle quali è già stata menzionata. Dovresti adottare 2 ampi approcci su come procedere.

Stabilire quali sono le variazioni in ciascuna delle variabili elencate di seguito in anticipo (il più possibile).

Approccio a) Se si ritiene che le variazioni delle variabili tra i titolari siano manageable creare 1 applicazione che gestisca tutti i titolari. Che cos'è manageable? È possibile eseguire un esercizio seguendo le sezioni Gestione variabili nella sezione delle variabili di seguito. Vedi se riesci a guidare le cose con metadata. Ciò è compreso comprendendo le variazioni tra gli inquilini per ciascuna variabile.

Approccio b) Se pensi che le variazioni siano troppe riconsiderare la realizzazione di queste app separate. Mentre vai avanti potresti trovare qualche comunanza. È possibile ridiffondere tale codice come un modulo comune ed esporlo come artefatto (privato) perpendicolare.

Approach a) Variazioni Manipolazione nelle variabili

1) cerca & tatto - Pelle Utilizzare uno CSS per ogni inquilino.

2) Dati Se lo schema JSON è diverso, si è verificato un problema. Suggerirei di andare solo per l'approccio b). Se vedi alcuni campi aggiunti + sottratti, stai bene. Raccomandiamo vivamente di creare uno schema JSON.

3) Moduli di immissione Si consiglia di guidare i moduli dallo schema JSON + alcuni metadati. Sareste in grado di utilizzare lo stesso templete AngularJS con un sacco di ng-if, ng-switch per le variazioni di tenant? In caso contrario, andare per FORM separato. Ti ritroverai con troppe "FORME separate"? Poi torni ad Approccio b).

4) Form Validation

È possibile schema JSON e decorare ulteriormente con gli attributi di convalida. (Non so cosa offre lo stack, ma le annotazioni di validazione Java Bean sono molto utili: puoi esternalizzarle al momento della compilazione e raggrupparle con il client in modo che i campi di input della form possano avere una validazione applicata pragmaticamente dallo schema.)

5) Flusso di lavoro Se viene visualizzata la logica di routing che cambia per client, utilizzare router angolari e definire le route per tenant.

6) Segnalazione Supponendo che si tratti di visualizzazioni personalizzate per inquilino. Quanto differiscono? Se è possibile utilizzare ng-if/ng-switch senza ingombrare i modelli, è possibile procedere altrimenti creare modelli separati, visualizzazioni (le rotte possono occuparsi delle viste).

7) i18n/l10n AngularJS ha un sacco di programmi di utilità come $ locale, ngPluralize, vari filtri come valuta, i dati, il numero. Acquista AngularJS i18n

In sintesi un buon metadata progettazione, Validation decorated JSON schema e good routing ([AngularJS routing ][2]) design aiuterebbe a mantenere un unico multi-tenant programma che permette di gestire attraverso una buona durata del prodotto.