Wspólne reguły walidacji dla klientów web i mobilnych

Dlaczego walidacja się rozjeżdża

Walidacja rozjeżdża się z prostego powodu: formularze webowe i mobilne są często tworzone w różnych momentach przez różne osoby. Jeden zespół dodaje szybką regułę na stronie, inny kopiuje starszą wersję do aplikacji i każdy idzie dalej.

Na początku różnica wydaje się niewielka. Potem jedna zmiana ją ujawnia. Hasło wymaga teraz 12 znaków zamiast 8. Numer telefonu musi zawierać kod kraju. Pole, które kiedyś było opcjonalne, staje się wymagane. Jeśli tylko jeden klient zostanie zaktualizowany, ten sam użytkownik może wprowadzić poprawne dane na jednym urządzeniu, a na innym zostać zablokowany.

Dlatego właśnie wspólne reguły walidacji mają znaczenie. Bez nich każdy klient staje się własną wersją prawdy.

Jak wygląda dryf w praktyce

Formularze rejestracyjne szybko pokazują problem. Na stronie "nazwa firmy" może być opcjonalna. W aplikacji mobilnej może wciąż być wymagana, bo ekran powstał miesiące wcześniej. Użytkownik wypełnia ten sam formularz dwa razy, uzyskuje dwa różne efekty i zakłada, że produkt jest zepsuty.

Zwykle dzieje się tak, gdy reguły są kopiowane w kilka miejsc i aktualizowane ręcznie. Terminy wydań to pogarszają: zmiana na web może pójść live dziś, a poprawka mobilna poczekać do następnego wydania aplikacji.

Niedopasowanie pojawia się często w podstawowych miejscach: pola wymagane, sprawdzenia formatu i ograniczenia biznesowe, takie jak wiek, wielkość zamówienia czy reguły rabatowe. Zespoły wsparcia tłumaczą potem, dlaczego jeden ekran przyjmuje wartość, a inny ją odrzuca. Z czasem użytkownicy przestają ufać komunikatom o błędach, a zespoły przestają ufać wydaniom.

Sama reguła rzadko jest prawdziwym problemem. Problem w tym, że ta sama reguła żyje w zbyt wielu miejscach.

Co powinno być takie samo wszędzie

Jeśli formularz zachowuje się inaczej na web i mobile, użytkownicy od razu to zauważą. Najbezpieczniejszym podejściem jest zdecydować, które reguły są uniwersalne i trzymać je jednakowo we wszystkich klientach.

Zacznij od podstaw. Pole nie powinno być wymagane na jednym urządzeniu i opcjonalne na innym, chyba że istnieje bardzo jasny powód produktowy. Sprawdzenia formatu też powinny się zgadzać. Email, telefon, data i podobne pola powinny używać tych samych wzorców wszędzie. Nawet mała różnica, np. jeden klient akceptuje spacje w numerze telefonu, a inny je blokuje, tworzy zamieszanie.

Limity długości i dozwolone znaki wymagają tego samego traktowania. Jeśli nazwa użytkownika akceptuje 30 znaków na mobile, a tylko 20 na webie, użytkownicy mogą zapisać dane, których inny klient później nie będzie mógł edytować. Ten sam problem pojawia się przy imionach, notatkach, kodach i identyfikatorach.

Reguły biznesowe są równie ważne. Jeśli użytkownicy muszą mieć określony wiek, należeć do wspieranego regionu lub mieć konkretny status konta, te sprawdzenia powinny działać tak samo na każdym ekranie.

Sformułowania nie muszą być identyczne wszędzie, zwłaszcza na węższych ekranach mobilnych, ale znaczenie powinno pozostać spójne. Jeśli jedna aplikacja mówi „Wprowadź poprawną datę”, a inna „Data nieobsługiwana”, użytkownicy mogą zakładać, że reguły są różne, nawet jeśli nie są.

Prosty test działa tutaj dobrze: jeśli użytkownik wpisze te same dane na web i mobile, powinien otrzymać ten sam wynik i te same podstawowe wskazówki, jak to naprawić.

Pozwól backendowi podejmować ostateczną decyzję

Szybkie informacje zwrotne na frontendzie są przydatne, ale nie powinny być ostatecznym słowem. Backend zawsze powinien decydować, czy dane są poprawne.

Web i mobile powinny nadal wychwytywać oczywiste problemy wcześniej. Powinny oznaczać brak wymaganych pól, zły format emaila, nieprawidłowe daty i wartości ewidentnie poza zakresem. To oszczędza czas i pomaga naprawić błędy przed naciśnięciem Wyślij.

Jednak backend widzi pełny obraz. Może sprawdzać reguły biznesowe powiązane z danymi na żywo, stanem konta, uprawnieniami, zapasami lub rekordami zmienionymi przez innego użytkownika sekundę temu. Kod promocyjny może wyglądać na ważny na telefonie, ale serwer może wiedzieć, że wygasł lub został już użyty.

Aby wspólne reguły działały dobrze, backend powinien zwracać błędy w formacie, który każdy klient rozumie. Unikaj niejasnych odpowiedzi typu „Nieprawidłowe dane”. Używaj stabilnych kodów błędów lub nazw reguł wraz z jasnym komunikatem.

Kilka przykładów wystarczy:

• required dla brakujących pól
• invalid_format dla złego wzorca emaila lub telefonu
• out_of_range dla wartości powyżej lub poniżej limitów
• not_allowed dla sprawdzeń na podstawie uprawnień lub statusu
• already_exists dla zduplikowanych emaili, nazw użytkowników lub ID

Te nazwy powinny pozostać stabilne między klientami. Małe różnice, takie jak email_invalid w jednej aplikacji i invalid_email w innej, tworzą niepotrzebne błędy.

Dobry test backendu jest prosty: jeśli ktoś pominie UI i wyśle zapytanie bezpośrednio do API, te same złe dane powinny zostać odrzucone z tego samego powodu.

Stwórz jedno źródło prawdy

Najczystsze rozwiązanie to jedna książka reguł. Jeśli każdy zespół pisze walidację w każdym formularzu web i każdym ekranie mobilnym, reguły będą się rozjeżdżać. Wspólne reguły działają lepiej, gdy reguła jest zdefiniowana raz, a każdy klient stosuje tę samą definicję.

To wspólne źródło może być schematem, modelem backendu lub centralną konfiguracją produktową. Dokładny format ma mniejsze znaczenie niż nawyk. Zdefiniuj pole raz zanim ktokolwiek zbuduje ekran. Trzymaj razem nazwę pola, typ danych, status wymagane, regułę formatu i ograniczenia biznesowe.

Pomaga też grupować reguły według obiektu biznesowego zamiast według urządzenia. Użytkownik, zamówienie, faktura lub żądanie rejestracji powinny mieć jeden zestaw reguł, który obowiązuje wszędzie. Dla każdego obiektu zapisz pola, sprawdzenia wymagane, reguły formatu, ograniczenia biznesowe i kody błędów zwracane przez backend.

To ułatwia bezpieczniejsze wprowadzanie zmian. Jeśli biznes zdecyduje, że numer telefonu jest opcjonalny, aktualizujesz jedną wspólną definicję zamiast szukać i zmieniać iPhone, Android, web i ekrany administracyjne.

Wersjonowanie też ma znaczenie. Zmiany reguł mogą zepsuć starsze aplikacje zainstalowane na telefonach klientów. Zamiast zastępować regułę bez śladu, wersjonuj zmianę, aby backend mógł obsłużyć starszych klientów przez krótki okres, podczas gdy nowe wersje są wdrażane.

Krótki krok przeglądu pomaga bardziej niż większość zespołów się spodziewa. Gdy reguła się zmienia, produkt może potwierdzić cel biznesowy, a wsparcie może wskazać realne problemy klientów, np. pole imię, które odrzuca typowe znaki interpunkcyjne, lub regułę adresu zbyt restrykcyjną.

Jeśli budujesz z AppMaster, takie podejście pasuje naturalnie, ponieważ logikę backendu, aplikacje webowe i natywne mobilne można zarządzać na jednej platformie no-code. Ta sama idea działa wszędzie: pisz reguły raz, trzymaj je centralnie i pozwól każdemu klientowi je stosować.

Prosty plan wdrożenia

Nie potrzebujesz dużego przerabiania, żeby naprawić dryf walidacji. Zacznij od jednego formularza i jasno zapisz reguły.

Najpierw wypisz każde pole i opisz je prostym językiem. Zanotuj, jaki rodzaj wartości akceptuje, czy jest wymagane, jaki format musi mieć i jakie warunki biznesowe są z nim związane. "Email jest wymagany" to za mało, jeśli jeden klient akceptuje zły format, a inny go blokuje.

Następnie wdroż sprawdzenia w backendzie jako pierwsze. Potem odwzoruj te same sprawdzenia w formularzu web i w formularzu mobilnym, aby użytkownicy otrzymywali szybki feedback przed wysłaniem.

Prosty porządek działa dobrze:

1. Napisz jedną listę reguł pole po polu.
2. Umieść reguły najpierw w walidacji backendu.
3. Dodaj dopasowane sprawdzenia na froncie web.
4. Dodaj te same sprawdzenia na mobile.
5. Przetestuj te same przykładowe dane wszędzie.

Testowanie to miejsce, gdzie zwykle pojawiają się ukryte różnice. Użyj małego zestawu poprawnych i niepoprawnych przykładów dla każdego pola: pustej wartości, złego formatu, wartości tuż poniżej limitu, wartości dokładnie na granicy i wartości tuż powyżej. Jeśli web i mobile zgadzają się z backendem w każdym przypadku, masz system, któremu można zaufać.

Przykład: formularz rejestracji klienta

Formularz rejestracyjny dobrze to obrazuje. Wyobraź sobie formularz z trzema polami: email, hasło i data urodzenia.

Na web i mobile formularz powinien reagować tak samo przed wysłaniem. Jeśli email jest pusty, oba powinny zatrzymać i pokazać ten sam komunikat. Jeśli format jest nieprawidłowy, oba powinny to wychwycić.

Reguła dla hasła musi być dokładnie taka sama. Jeśli minimum to 8 znaków, powinno być 8 wszędzie, a nie 6 na web i 10 na mobile. Małe niedopasowania mylą użytkowników szybko, zwłaszcza gdy przełączają urządzenia.

Data urodzenia to miejsce, gdzie logika biznesowa często się rozjeżdża. Jeśli produkt zezwala tylko na rejestracje od osób powyżej 18 lat, oba klienty powinny używać tej samej reguły granicznej i tej samej definicji "dzisiaj". W przeciwnym razie ten sam użytkownik zostanie zatwierdzony na stronie, a odrzucony w aplikacji.

Backend nadal musi ponownie wszystko sprawdzić po otrzymaniu żądania. To tam wykryjesz duplikaty kont, edytowane żądania i starsze wersje aplikacji nadal wysyłające nieaktualne dane.

Komunikaty też powinny być jasne i spójne. Dobre przykłady to: "Wprowadź swój adres email", "Wprowadź prawidłowy adres email", "Hasło musi mieć co najmniej 8 znaków" oraz "Konto z tym emailem już istnieje". Gdy użytkownicy widzą ten sam język wszędzie, wsparcie jest prostsze, a zaufanie rośnie.

Błędy, które powodują dryf

Większość problemów z walidacją nie wynika z jednej oczywiście złej reguły. Wynikają z małych niedopasowań, które narastają.

Jednym z częstych błędów jest ukrywanie reguły tylko w jednym kliencie. Aplikacja na iPhone może wymagać numeru telefonu, podczas gdy aplikacja web traktuje go jako opcjonalny. Kolejny błąd to stosowanie różnych wzorców dla tego samego pola. Formularz webowy może pozwalać na spacje w kodzie pocztowym, a aplikacja Android je blokować, albo jeden klient akceptuje znak plus w numerze telefonu, a inny go usuwa.

Poważniejszym problemem jest zbyt duże poleganie na UI. Walidacja po stronie klienta pomaga użytkownikom szybciej naprawiać błędy, ale nigdy nie wystarczy sama w sobie. Starsze aplikacje, dziwactwa przeglądarek i bezpośrednie żądania do API mogą wysyłać złe dane, jeśli backend nie wymusza tych samych ograniczeń biznesowych.

Słabe komunikaty o błędach pogarszają sytuację. "Nieprawidłowe dane" nie mówi użytkownikowi, co poprawić. Jasny komunikat już tak. Starsze wersje aplikacji to kolejna łatwa do przeoczenia rzecz. Jeśli nowe wydanie dodaje pole wymagane, starsi klienci mogą przez tygodnie wysyłać niekompletne dane.

Gdy walidacja ciągle się rozjeżdża, zwykłe przyczyny to: ukryte pola wymagane, różne reguły formatu, słabe sprawdzenia backendu, niejasne komunikaty o błędach i brak planu dla starszych wersji.

Kontrole przed wydaniem, które łapią problemy

Zanim wypuścisz wersję, testuj ten sam formularz w ten sam sposób na każdym kliencie. Użyj jednego małego zestawu przykładowych danych i sprawdź je przez aplikację web, aplikację mobilną i API backendu. Jeśli jeden klient zaakceptuje wartość, a inny ją odrzuci, wasze wspólne reguły walidacji nie są jeszcze naprawdę wspólne.

Zacznij od podstawowych przypadków. Zostaw pola wymagane puste, wpisz źle sformatowane wartości i wypróbuj przypadki brzegowe, takie jak data dokładnie na granicy, imię z jednym znakiem lub pole wypełnione do maksymalnej długości.

Twoja kontrola przed wydaniem powinna odpowiedzieć na kilka prostych pytań: czy web odrzuca te same złe dane co mobile, czy backend nadal odrzuca nieprawidłowe dane nawet jeśli klient ich nie złapie, oraz czy użytkownicy wszędzie widzą to samo znaczenie w komunikacie o błędzie?

Sprawdzenie backendu ma największe znaczenie. Jeśli ktoś ominie UI, użyje starszej aplikacji lub wyśle dane bezpośrednio do API, wynik powinien pozostać bezpieczny i przewidywalny.

Warto też porównać teksty błędów obok siebie. Jeśli web mówi "Wprowadź prawidłowy email", a mobile "Nieznany błąd", ludzie założą, że aplikacje zachowują się inaczej, nawet gdy reguła jest ta sama.

Po wydaniu obserwuj zgłoszenia do wsparcia i komentarze użytkowników przez kilka dni. Skargi typu "działało na telefonie, a nie na desktopie" zwykle szybciej wskażą lukę walidacji niż jakikolwiek dashboard.

Czystsze kolejne kroki

Jeśli twoje formularze wciąż psują się na różne sposoby w web i mobile, nie próbuj naprawić wszystkiego naraz. Zacznij od tego, który powoduje najwięcej powtarzających się problemów, zwykle rejestracji, kasy lub edycji profilu.

Przenieś rygorystyczne reguły najpierw do logiki backendu. To obejmuje pola wymagane, sprawdzenia formatu, wykrywanie duplikatów i ograniczenia biznesowe, takie jak wiek, typ konta czy region. Potem pozwól web i mobile odwzorować te same sprawdzenia, żeby dawać użytkownikom szybki feedback.

Pisz reguły prostym językiem. Zamiast "zweryfikuj status klienta" napisz "Klienci biznesowi muszą podać NIP" lub "Numer telefonu jest opcjonalny, chyba że włączone są powiadomienia SMS". Jasne sformułowania ułatwiają projektantom, deweloperom, testerom i zespołom wsparcia wychwycenie braków przed wydaniem.

Jeśli chcesz zmniejszyć powtarzalną pracę, AppMaster może pomóc, bo pozwala zespołom budować backend, web i natywne aplikacje mobilne z jednego systemu. To ułatwia utrzymanie spójnej logiki biznesowej, jednocześnie dając użytkownikom szybkie informacje zwrotne na każdym kliencie.

Celem nie jest idealny formularz z dnia na dzień. Celem jest mniej niespodzianek, mniej zgłoszeń do wsparcia i walidacja web i mobile, która pozostaje spójna w miarę rozwoju produktu.