Co sądzicie o granular degradation? Nasz backend łączy się z innymi aplikacjami ( ktore są nie stabilne ) i te apki nie zawsze trzymają się kontraktu ( czasami poleci null/undefined ). Mamy problem co zrobić w tym momencie, zabić cały request czy pozwolić frontendowi samemu wyłączać bloki ui które nie mogą być obsłużone przez zły kontrakt. Prawdopodobnie użyjemy .parse od zoda :D
Hej, ciężko odpowiedzieć bez znajomości szczegółów. Zależy m.in od tego czy: - możecie wyłączyć bloki i użytkownik dalej będzie mógł korzystać z aplikacji, tj czy inne bloki będą potrzebne do podjęcia decyzji. Np w fb nic się nie stanie jeżeli nie będzie dostępny chat. Ale np w Forex jak wyłączysz niektóre wykresy to użytkownik może nie być w stanie podjąć decyzji w odpowiedni sposób - zależy jakie są to bloki (np wyłączenie głównej nawigacji może zablokować całą aplikację, użytkownik nie będzie w stanie nic zrobić) - co jeżeli wszystkie bloki na stronie się wywalą? Czy taki scenariusz jest możliwy? Czy to obsługujecie, np rerender całej strony , czy użytkownik musi sobie radzić - czy użytkownik może coś zrobić? Np jak kliknie refresh to problem się naprawi Tych pytań jest więcej, ciężko coś doradzić bez wejścia głębiej w temat. Moze być to dobre rozwiązanie, a może być źle, ale trzeba znać kontekst aby to stwierdzić. Tak bardzo ogólnie to jestem zwolennikiem prasowania i wyświetlania błędów na UI. Ale też nie w każdym przypadku się to sprawdzi. ZOD polecam, świetnie nadaje się do takich rzeczy i uczy BE, że nie mogą sobie zmieniać kontraktu z czapy. Możecie też zrobić BFf (backend for frontend), mogliby to po części rozwiązać problem kontraktów. Tj jeżeli przyjmiecie ze BE ma poprawić kontrakty również na BFF, ale tylko te od strony BE to będziecie mieli spójne kontrakty od strony FE
Hej, źle nazwałem termin, moja wina. Chodziło mi o Graceful Degradation. Przeciwieństwem jest Progressive Enhancement. www.w3.org/wiki/Graceful_degradation_versus_progressive_enhancement
Co sądzicie o granular degradation?
Nasz backend łączy się z innymi aplikacjami ( ktore są nie stabilne ) i te apki nie zawsze trzymają się kontraktu ( czasami poleci null/undefined ).
Mamy problem co zrobić w tym momencie, zabić cały request czy pozwolić frontendowi samemu wyłączać bloki ui które nie mogą być obsłużone przez zły kontrakt.
Prawdopodobnie użyjemy .parse od zoda :D
Hej, ciężko odpowiedzieć bez znajomości szczegółów. Zależy m.in od tego czy:
- możecie wyłączyć bloki i użytkownik dalej będzie mógł korzystać z aplikacji, tj czy inne bloki będą potrzebne do podjęcia decyzji. Np w fb nic się nie stanie jeżeli nie będzie dostępny chat. Ale np w Forex jak wyłączysz niektóre wykresy to użytkownik może nie być w stanie podjąć decyzji w odpowiedni sposób
- zależy jakie są to bloki (np wyłączenie głównej nawigacji może zablokować całą aplikację, użytkownik nie będzie w stanie nic zrobić)
- co jeżeli wszystkie bloki na stronie się wywalą? Czy taki scenariusz jest możliwy? Czy to obsługujecie, np rerender całej strony , czy użytkownik musi sobie radzić
- czy użytkownik może coś zrobić? Np jak kliknie refresh to problem się naprawi
Tych pytań jest więcej, ciężko coś doradzić bez wejścia głębiej w temat. Moze być to dobre rozwiązanie, a może być źle, ale trzeba znać kontekst aby to stwierdzić.
Tak bardzo ogólnie to jestem zwolennikiem prasowania i wyświetlania błędów na UI. Ale też nie w każdym przypadku się to sprawdzi. ZOD polecam, świetnie nadaje się do takich rzeczy i uczy BE, że nie mogą sobie zmieniać kontraktu z czapy. Możecie też zrobić BFf (backend for frontend), mogliby to po części rozwiązać problem kontraktów. Tj jeżeli przyjmiecie ze BE ma poprawić kontrakty również na BFF, ale tylko te od strony BE to będziecie mieli spójne kontrakty od strony FE
@refixshow597 jak definiujesz "granular degradation"? Możesz odesłać do jakiegokolwiek dokumentu?
Hej, źle nazwałem termin, moja wina.
Chodziło mi o Graceful Degradation. Przeciwieństwem jest Progressive Enhancement.
www.w3.org/wiki/Graceful_degradation_versus_progressive_enhancement