Gestione delle dipendenze per facciate / adattatori ai servizi cloud (SemVer?)

2

Supponiamo che abbia una libreria, che fondamentalmente funzioni come facciata per alcuni servizi cloud (ad esempio l'API JavaScript che avvolge le chiamate di rete verso un qualche servizio RESTfull). E una volta che quel servizio introduce un cambiamento incompatibile con le versioni precedenti.

Ci sono due possibili scenari a cui riesco a pensare, e non sono sicuro di come gestire entrambi nel modo migliore.

  1. In un caso più semplice, la mia libreria in qualche modo riesce a gestire quell'incompatibilità con le versioni precedenti (e ora diventa un adattatore). Quindi spedisco una versione patch perché l'API della mia libreria non è cambiata, e la versione precedente ora ha un qualche tipo di comportamento bacato (si basa su API esterne che non esistono più). Il problema qui è che tutti i programmi già costruiti, così come quelli che usano qualche tipo di blocco delle dipendenze, sono ora danneggiati e devono aggiornare le loro dipendenze. Bene, posso dire che non è un mio problema, ma mi dà fastidio un po '.

  2. In un caso più complesso e più reale, la mia libreria non può astrarre quell'incompatibilità all'indietro e ne trapela, quindi devo modificare anche un'API pubblica della mia libreria. Quindi, spedisco una versione principale. Il problema è che rompe l'intero punto di SemVer, in cui l'utente suppone di avere la libertà di decidere dove vogliono avere un aggiornamento importante o no, perché una versione principale precedente dovrebbe funzionare insieme a quella nuova. Ma non è e non può essere patchato.

Capisco che l'approccio SemVer non dovrebbe gestire tali casi. Ma non ho idea di cosa dovrebbe. C'è qualche approccio a questi casi là fuori?

    
posta Roman Bekkiev 02.08.2018 - 12:08
fonte

1 risposta

0

L'approccio migliore per questo è definire la tua libreria di wrapper in termini della versione più recente dell'API del servizio web (la presunzione è che le persone vorranno migrare verso quello, e che esporrà nuove funzionalità ma che altrimenti sarebbero simili a la vecchia API).

Avere che il wrapper API rilevi automaticamente la versione del servizio remoto e garantisce la compatibilità con le versioni precedenti.

E tutte le API che sono andate via (o cambiate materialmente) - contrassegnano DEPRECATED (il sovraccarico particolare se necessario) - ma continuano a supportare.

In questo modo, quando gli utenti della libreria wrapper incontrano server nuovi o vecchi, funzioneranno in entrambi i modi. E riceveranno degli avvertimenti (relativi alla deprecazione) se stanno utilizzando API deprecate, in modo che possano migrare alle nuove API come è logico per i loro progetti.

NOTA: questa forma di retrocompatibilità è facile da fare e buona da fare. Ma è incompleto. Se si desidera che i vecchi client lavorino con server più recenti (spesso una buona idea), è necessario utilizzare un approccio SIMILAR sul lato server, consentendo di rilevare versioni più recenti (rispetto alle versioni precedenti) dell'API del servizio Web RESTFULL.

Ho usato questo approccio in precedenza su diversi progetti, e ha funzionato molto bene nel corso degli anni, consentendo ai clienti di utilizzare le API che ho costruito per migrare il proprio codice sulla propria pianificazione, in quanto interagiscono con il cambiamento versioni del servizio / prodotto sottostante.

    
risposta data 02.08.2018 - 16:25
fonte

Leggi altre domande sui tag