Quindi, abbiamo SOA sul backend (BE) e sul frontend (FE) abbiamo micro-frontend (i micro-frontend separati sono caricati come componenti nell'app frontend quando necessario, quindi il processo interno le chiamate tra di loro sono possibili, a differenza dei servizi di back-end, dove devono essere effettuate chiamate tra processi).
Sulla BE abbiamo un servizio Auth
e un altro servizio Bananas
. Sulla FE abbiamo anche un auth
micro-frontend e qualsiasi altro bananas
micro-frontend. Immagina che access token
di un utente sia scaduto e effettua una richiesta a /bananas/create
. Ognuno dei nostri servizi BE ovviamente convalida il token di accesso ricevuto su ogni richiesta e, se invalido, restituisce 401
. Vogliamo implementare la funzionalità refresh token
(il token di aggiornamento verrà passato insieme al token di accesso con ogni richiesta).
Ora la domanda è: se viene ricevuta una richiesta con un token scaduto:
- dovrebbe essere il servizio
Bananas
, quando si vede il token è scaduto, fai un chiama al servizioAuth
per convalidarerefresh token
e ricevi una nuova coppia di token, quindi esegui il business delle banane e rispondi con le coppie di token + i dati effettivi sulle banane. Chiamata All in 1. Oppure ... - se il
Bananas
restituisce ancora401
, il micro-frontend banane delega al micro-front-end auth per chiamare il servizioAuth
per nuovi token, quindi restituirlo al micro-frontend banane e fai una nuova chiamata al servizioBananas
, con token validi?
Questo è il dilemma del design tra me e il mio collega. Il mio punto è che non desidero avere 3 richieste di risposta alle richieste di risposta. Sostiene che il servizio Bananas
dovrebbe sempre restituire solo i dati delle banane nei suoi oggetti risposta e non avere casi in cui restituisce anche coppie di token.
Per come la vedo, entrambi i nostri punti sono validi, ma non abbiamo l'esperienza e le conoscenze per decidere quale ha una priorità più grande / quale è il design migliore.