Kompatybilność wsteczną najłatwiej wytłumaczyć, a nawet zobaczyć, na codziennym przykładzie. Pewnie większość z Was kojarzy, że w telefonach jeszcze niedawno standardem były ładowarki ze złączem USB Typu B, jednak od pewnego czasu standardem są już złącza typu C.
Jak możecie zauważyć na diagramie - oba te złącza są kompletnie różne. Czyli po prostu wtyczka pasująca do gniazda pierwszego typu, nie będzie pasowała do gniazda drugiego złącza. Wtedy możemy powiedzieć, że te dwa interfejsy(wtyczki)nie są z sobą kompatybilne.
Mimo tworzenia nowych telefonów, producenci przez długi czas nie decydowali się na wprowadzenie nowego standardu(USB-C) właśnie ze względu na kompatybilność wsteczną. Po wprowadzeniu nowego modelu z USB-C wszystkie ładowarki i akcesoria dobrze współpracujące z poprzednim standardem i poprzednią wersją telefonu stałyby się bezużyteczne(przynajmniej bez dodatkowych adapterów).
Istniała zatem realna obawa, że w związku z brakiem kompatybilności wstecznej klienci niechętnie kupowaliby nowszy model.
Jaka jest główna definicja kompatybilności wstecznej?
Określona zmiana jest w pełni kompatybilna pod względem interfejsów z resztą systemu, jeżeli obszar po zmianie jest w stanie bez żadnych problemów działać z pozostałymi komponentami. Inaczej mówiąc dowolny element systemu w starej wersji jest w stanie działać z nowym elementem bez potrzeby żadnych dodatkowych zmian.
Niekompatybilność jest więc odwrotnością tego stanu. Występuje ona wtedy, gdy zmiana w jednym systemie A może spowodować popsucie integracji innego systemu B z systemem A. Może ale nie musi, ponieważ system B nie musi korzystać ze zmienionej ścieżki.
Najlepiej jednak pokazać to na kilku przykładach.
Przy ich analizie zastosujemy następujący schemat:
zidentyfikujemy, kto jest klientem dla usługi, która jest dostarczana za pomocą tworzonego przez nas komponentu,
jak wygląda brak kompatybilności,
jakie mogą być skutki tego braku,
w jaki sposób można wykrywać niekompatybilność,
jak jej przeciwdziałać.
Prosta aplikacja webowa
Możemy zacząć od najbardziej klasycznego przypadku: frontend, API i baza danych. W tym przypadku mamy tylko 3 elementy. Bardzo łatwo jest tu zidentyfikować klientów dla każdej z usług:
klientem dla bazy danych jest API,
klientem dla API jest aplikacja frontendowa,
klientem dla aplikacji frontendowej jest użytkownik.
Tak więc starając się zachować kompatybilność wsteczną każdy z wymienionych elementów powinien dbać o zapewnienie ciągłości integracji z systemem dla niego klienckim.
Ten przykład jest akurat wyjątkowy. Większość prostych aplikacji webowych tworzona jest jako jedna całość, wdrażana wspólnie. W związku z tym nie musimy się zbyt mocno przejmować tym, czy poszczególne elementy są ze sobą kompatybilne.
Jednak kompatybilność wsteczna ma tu znaczenie w kilku przypadkach:
gdy poszczególne elementy są używane przez więcej niż jednego klienta
lub gdy wdrażamy niezależnie każdy z elementów systemu i zależy nam na nieprzerwanym działaniu aplikacji przez cały czas wdrożenia(koncepcję zero downtime deployment omawiam w artykule[])
nasza aplikacja jest hostowana na wielu serwerach jednocześnie
Wtedy deployment zawsze podmieni aplikacje na jednym serwerze jako pierwszym, więc nowa wersja powinna być kompatybilna wstecz z poprzednią.
Omówmy więc każdy z interfejsów.
Serwis→ baza danych
Przykład niekompatybilności
Dobrym przykładem niekompatybilności na poziomie bazy danych jest:
Czym jest kompatybilność wsteczna?
Prosta aplikacja webowa
Serwis → baza danych