Come integrare la vecchia interfaccia utente in Microservice

0

Abbiamo circa 10 applicazioni in un Monolite che devono essere refactored in Microservices.

Seguendo un approccio Agile, vorremmo dividere il lavoro in sezioni verticali in cui ogni sezione sarebbe utile per l'utente. Ogni sezione includerebbe un livello di persistenza, un servizio e un'interfaccia utente. Tuttavia, non siamo sicuri su come gestire il livello dell'interfaccia utente. Dovremmo collegare i nostri nuovi microservizi alla vecchia interfaccia utente o creare una nuova interfaccia utente che sarebbe disponibile per alcuni utenti?

La prima opzione richiederebbe molto lavoro per cablare il microservice nella vecchia interfaccia utente. Inoltre, alla fine dovremmo collegare i servizi in una nuova interfaccia utente. Quindi, due volte il lavoro. La seconda opzione richiederebbe due UI in esecuzione in parallelo e otterrebbe sicuramente meno traffico fino al termine del progetto. Dato che probabilmente avrà un sottoinsieme di utenti che potrebbero non usarlo spesso, mi chiedo, quanto sarebbe utile. La seconda opzione sembra avere senso per me, ma abbiamo giocato con un'altra opzione.

L'altra opzione sarebbe semplicemente creare il livello di servizio e aggiungere una nuova UI come epica separata. Il test del servizio potrebbe essere eseguito tramite uno strumento di test API, ad es. Postman. Questo approccio sembra più semplice all'inizio, ma presenta problemi. In primo luogo, sembra volare contro un approccio Agile e segue più di una metodologia Waterfall. Pertanto, non riceviamo feedback incrementali reali da parte dell'utente, poiché in effetti non vedranno nulla di utile fino a quando l'interfaccia utente non sarà completata.

Quindi sono sicuro che ci sono molti modi per affrontare questo problema, ma ci chiediamo se esiste un modo tipico per risolverlo.

    
posta navig8tr 27.11.2018 - 17:48
fonte

2 risposte

4

Per ottenere la risposta alla tua domanda, devi chiederti quale valore creerai completando il lavoro in modo incrementale. In agile, l'idea è di non fare il lavoro a fette solo per divertimento, ci dovrebbe essere un valore da esso. Nella sua forma più semplice, quella potrebbe essere la riparazione del rischio. Confermando che ottieni i medesimi risultati dai microservices, ottieni il valore della conoscenza a rischio ridotto con la tua ultima opzione, solo testando il livello di servizio. Sono d'accordo che questo è il meno agile perché sei ancora impegnato con l'intero refactoring, ma è un grande passo avanti rispetto alla semplice integrazione alla fine.

Se ci sono dei grandi guadagni in termini di prestazioni o di qualità che si ottengono dalla transizione ai microservizi, potrebbe valere la pena di collegarli all'interfaccia utente precedente. Sì, aggiungerà tempo e costi, ma se il valore di capitalizzazione beneficia dell'uso anticipato della nuova architettura lo garantisce, potrebbe essere un buon compromesso.

Infine, ecco un'altra cosa da considerare:

Quanto sono simili l'interfaccia utente vecchia e nuova? Se sono troppo simili, potresti chiederti perché. Nella maggior parte delle ricostruzioni di grandi dimensioni, le esigenze dell'utente sono cambiate e il nostro modo di pensare sull'interfaccia utente / UX efficace si è evoluto. Nella maggior parte di questi progetti, i team dovrebbero chiedersi se possono risolvere meglio le loro esigenze degli utenti. Se è così, concentrati sui nuovi flussi di IU dove c'è di più da guadagnare per l'utente: questo neutralizzerà ogni peggioramento derivante dall'affrontare 2 UI e può offrire un valore davvero enorme. Quindi, estrai i servizi dall'applicazione monolitica ai microservizi che supportano prima tali flussi. Le probabilità sono che non saranno linee pulite e finirai per spostare alcune cose che non sono strettamente necessarie per quei flussi, ma va bene. Questo approccio sarebbe probabilmente il più orientato al valore se si adatta alla tua situazione.

Un ultimo punto: se stai creando una nuova UI duplicata, fai attenzione a verificare che i nuovi servizi funzionino nella nuova interfaccia utente ok. I vecchi sistemi hanno tutti i bambini di casi limite strani che si sono sviluppati nel corso degli anni. Ho visto molti progetti come questo collegare a una nuova interfaccia utente e perdere alcune sfumature nella vecchia interfaccia utente che causa gravi problemi per l'utente.

    
risposta data 27.11.2018 - 18:17
fonte
0

Se si desidera mantenere la vecchia interfaccia utente, sarebbe simile a questa:

Db > App > L'interfaccia utente è quella che probabilmente è la tua vecchia applicazione, ma quando inserisci i microservizi, assomiglierebbe a:

Db > microservice > App > UI, con microservice > App come livello http (s).

In questo approccio, l'app verrebbe modificata pesantemente ma finché il contratto dell'interfaccia utente è soddisfatto, 0 modifiche.

Non lo consiglierei comunque, una nuova interfaccia utente renderebbe la tua app più moderna per uno sforzo minore rispetto all'implementazione dei micro servizi nella maggior parte dei casi.

    
risposta data 27.11.2018 - 22:02
fonte

Leggi altre domande sui tag