Qual è il modo migliore di costruire un'interfaccia utente amministrativa per un'applicazione SPA esistente?

Question

Qual è il modo migliore di costruire un'interfaccia utente amministrativa per un'applicazione SPA esistente?

#1 da (1 voti)
#2 da (0 voti)

2

Sto lavorando su un'applicazione in cui l'interfaccia lato client e il server back-end sono applicazioni completamente separate. Il back-end è scritto in Ruby e serve solo JSON via HTTP. Il client è un'applicazione di browser a pagina singola completamente "statica" che comunica con l'API JSON. Ora ho bisogno di creare un'interfaccia amministrativa che verrà utilizzata per curare il contenuto servito dall'API JSON.

Vedo un certo numero di modi in cui posso concepire questo:

Estendi l'applicazione a pagina singola esistente. Inizialmente questo sembrava il modo più ovvio per farlo perché ho già un sacco di codice esistente per comunicare con l'API. Il rovescio della medaglia che vedo qui è che la sezione di amministrazione si sentirebbe molto attaccata. Le preoccupazioni dell'amministratore sono in gran parte ortogonali rispetto alla funzionalità della SPA esistente e non sono convinto che la quantità di riutilizzo del codice potrebbe effettivamente giustificare la combinazione delle due applicazioni.
Un'applicazione a pagina singola separata. Questo potrebbe funzionare bene. Dovrei duplicare del codice dalla SPA esistente, ma penso che abbia un po 'più senso dal momento che l'interfaccia di amministrazione sembra davvero un'applicazione separata. L'area di amministrazione non ha bisogno di un'interfaccia utente spettacolare, tuttavia, e un'applicazione web tradizionale resa server potrebbe essere un modo per ridurre lo sforzo di sviluppo richiesto per creare l'interfaccia di amministrazione.
Un'applicazione web resa dal server. Tutte le applicazioni Web renderizzate dal server che ho costruito in passato sono state direttamente collegate a un database. Questo, tuttavia, dovrebbe comunicare con l'API JSON su ogni richiesta. Sono sicuro che sia possibile ma non mi è molto familiare e non vedo molte discussioni su questo approccio.
Un'applicazione Web resa dal server nello stesso processo dell'API JSON. In questo modo le pagine di rendering del codice per l'interfaccia di amministrazione possono accedere direttamente al livello db / modello e non è necessario effettuare richieste HTTP separate per il rendering della pagina. La parte che non mi piace di questo è che rispetta il codice API con il codice UI e preferirei tenerle completamente separate.

Ho preso in considerazione i compromessi in ciascuno di questi casi e sarei molto interessato a sentire le opinioni altrui. Hai sviluppato un'architettura simile? Quale approccio hai seguito e perché?

api web-development web-applications json client-server

posta scttnlsn 23.09.2014 - 15:14

fonte

2 risposte

Leggi altre domande sui tag api web-development web-applications json client-server

Utilizzare i casi correlati in sequenza, come affrontarli? Accoppiamento di implementazione

score 1 · Answer 1

Penso che l'opzione 2 sia la soluzione migliore. Sebbene i siti pubblico e di amministrazione siano correlati e utilizzino lo stesso DB molto probabilmente, i casi di utilizzo e i flussi di lavoro dell'amministrazione generalmente si sovrappongono poco ai casi d'uso e ai flussi di lavoro nel sito pubblico. Pertanto, il sito di amministrazione avrà probabilmente un proprio insieme distinto di business logic. Puoi certamente spostare il codice che è comune nelle librerie che sono condivise in modo da poter riutilizzare, se del caso, sia l'interfaccia utente sia il codice dominio.

Un app / sito di amministrazione separato significa anche che puoi essere distribuito in modo indipendente e possibilmente chiuderlo meglio. Ad esempio, potrebbe essere necessario consentire l'accesso dalla tua intranet.

score 0 · Answer 2

A parità di altre condizioni, preferisco non utilizzare due architetture diverse nella stessa applicazione, a meno che non ci sia un buon motivo per farlo (ad esempio il supporto nativo per dispositivi palmari).

Detto questo, la tua soluzione dipende interamente dalle tue esigenze. Se tutta l'interfaccia utente amministrativa è impostata su alcuni valori nel database e non verrà mai eseguita all'esterno della tua intranet, ci sono tutti i tipi di cose (come l'API JSON) che puoi fare a meno. Potrebbe essere più semplice mettere in piedi un'interfaccia utente con rendering server più tradizionale.

D'altra parte, hai già un sacco di cose sulla SPA già fatte, e alcune potrebbero essere riutilizzabili. Il look and feel coerente (e operativo) è sempre bello. Come ho detto, dipende interamente da quali sono le tue esigenze.

La tua decisione seguirà essenzialmente lo stesso processo di pensiero che hai attraversato in origine quando hai deciso di creare un'applicazione SPA, ma con requisiti diversi e, eventualmente, con un risultato diverso.

Non sono sicuro di cosa intendi quando dici che il codice API sarà compatibile con il codice dell'interfaccia utente. L'obiettivo principale di avere un'API JSON è consentire di essere agnostici sul modo in cui scrivi la tua interfaccia utente. L'API potrebbe avere ulteriori metodi o endpoint aggiunti per supportare le operazioni amministrative, ma ciò non influisce affatto sull'interfaccia utente esistente.