Tworzenie aplikacji internetowych – case study mojego doświadczenia z serwisem KRS

Tworzenie aplikacji internetowych to nie jest łatwe zadanie. W tym artykule opowiem o moim doświadczeniu z serwisem KRS. Pokaże proste wnioski których wdrożenie mogło by przynieś obniżenie kosztów związanych z infrastrukturą serwerowa systemy KRS.

Frustracja pojawiająca się w trakcie użytkownaia portalu

Piszę ten wpis, będąc sfrustowanym użytkownikiem serwisu rządowego – ekrs.ms.gob.pl. Być może treść dotrze do osób tworzących ten serwis i zarządzających. Jako software house mieliśmy okazję uczestniczyć w projekcie tworzonym na zlecenie rządu. Niestety projekt ten nie należał do szczególnie dobrze zarządzanych.

Za kulisami był wielki haos, osoby dobrane bardziej z przypadku, brak dedykowanych architektów do systemu z dobrym doświadczeniem. To wszystko sprawiało że powstająca aplikacja miała całą masę krytycznych bugów. Dodatkowo to co nas bardzo bolało to ciśnięcie na dostarczenie funkcjonalności skupiające się na opisanych wymaganiach w dokumencie przeteragowym. Gdy podczas developmentu już wiedzieliśmy, że funkcje te są mało istotne, lub powinny być zrobione inaczej. Nikt niestety nie był wstanie podjąć ryzyka związanego z rozliczeniem późniejszym za projekt. Biznesowo związane ręce.

Nie mamy remedium na takie problemy bo rozumiem ideę stojącą za tym by publiczne pieniądze wydawać jak najlepiej i jak najbardziej przejrzyście. Jednakże tworzenie tego typu aplikacji internetowych wymaga procesu „wirującego”, takiej pralki wiedzy – robimy coś, zaczynamy rozumieć lepiej, ulepszamy i tworzymy kolejne wersje, ale cały czas w pracy z użytkownikiem. Tu niezbędnym elementem jest użytkownik. Badamy jego doświadczenia i problemy. Sprowadzamy czy system wciąż jest odpowiednio intuicyjny, bo jako developerzy potrafimy coś bardzo skomplikować, i to co dla nas jest naturalnie nie koniecznie jest „zjadliwe” dla przysłowiowego Kowalskiego.

Konsekwencje błędu KRS

Niby nic, ot błąd KRS. Niestety dla mnie oznacza to całkiem sporą stratę czasu, w dniu wczorajszym mijał ustawowy czas na złożenie dokumentów. Jako przedsiębiorca za uchybienie tego terminu mogę zostać ukarany. W związku z awarią nie mam musze teraz zbierać „materiał” na swoją obronę. W dniu wczorajszym podjołem 5 prób załadowania dokumentów. Tym samym doświadczyłem irytującego mnie designu aplikacji, gdzie wybór daty możliwy jest tylko z kontrolki „pickera”.

Co warto poprawić w serwisie

Logowanie

Zacznijmy od logowania. Logowanie to bezlitosny proces na którym wielu użytkowników odpada. Dlatego warto poświecić mu więcej czasu. Spinery (czyli takie ikonki które informują że strona na coś czeka, typu kręcące kółeczko) są ważnym elementem tego procesu. Gdy internet działa wolno, lub serwery są przeciążone użytkownik po kliknięciu zaloguj nie wie co się dzieje. Bo w sumie nie wie czy kliknoł dobrze, zaczyna ponawiać klik. Serwer który już jest przeciążony dostaje dodatkowego „kopa” od setek tysiecy użytkowników. To nie jest ich wina, to wina słabego UX’a.

Dobrym pomysłem by sprawdzić jak Twoja strona zachowuje się gdy ktoś ma wolny internet to ustawić w przeglądarce chrome symulowanie wolnego łącza :

Następnie przejście przez stronę i zobaczenie jak będzie się zachowywać pod dużym obciążeniem pozwoli nam na pierwszą diagnozę problemu.

Komunikat który został już odczytany – nie się więcej nie pojawia

W każdej przeglądarce jest tzw „local storage”. Twórcy aplikacji mogą z niego korzystać by zapisywać informację o tym co użytkownik już odczytał lub jakie ustawienia na swoim lokalnym komputerze zrobił. Oczywiście trzeba tego użytkownika poinformować że coś takiego jest robione jeśli zbieramy tam dane pozwalające na profilowanie tego użytkownika. Ale jeśli to tylko informacja o tym czy użytkownik odczytał informację to nawet nie musimy tego robić.

Powyższy komunikat pojawia mi się za każdym razem, pomimo że nie swoje dokumenty podpisuje w inny sposób, to nie jest prawidłowe miejsce do jego wyświetlania. Komunikat powinien pojawiać się wtedy gdy jesteśmy blisko zdarzenia którego dotyczy. W serwisie KRS możemy przeglądać dokumenty i składać nowe. Ten komunikat dotyczy wyłączeni składania nowych dokumentów i wyłącznie użytkowników którzy chcą podpisywać je w określony sposób. Po kliknięciu w niego około 30 razy przez ostatnie dwa dni, nie chce na niego już dłużej patrzeć 😉

Selektor daty – pozwól użytkownikowi wpisać datę z klawiatury

Powyżej widzimy formularz w którym konieczne jest ustawienie za jaki okres składamy bilans. Serwis tworzony z myślą o użytkownikach mógłby mieć z boku przycisk „Składam sprawozdanie za rok 2023”. Po jego naciśnięciu przedział dat ustawiał by się od razu za okres. Nie znam co prawda liczb, ale patrząc po mojej pracy z tym serwisem, od wielu lat, co roku klikam to rozwijane menu

Walidacja zrobiona zbyt późno

Dodając dokument w formacie XML z łatwością można odczytać z niego potrzebne daty. Składam dokumenty dotyczące kilku spółek i czas ładowania każdego jest długi. Po jego załadowaniu możliwe jest odczytanie danych i ustawienie ich w odpowiednich polach. Dlatego zamiast wyświetlać mi komunikat:

Błąd!Data sporządzenia dokumentu podana w zgłoszeniu nie zgadza się z datą sporządzenia dokumentu podaną w w pliku xml

Wystarczy zapytać czy chcesz ustawić data sporządzenia dokumentu w pliku to xxxx-xx-xx – czy chcesz użyć tej daty? Może pójdźmy dalej. Skoro określam jaki typ dokumentu wysyłam do repozytorium (Roczne sprawozdanie finansowe) i nie mogę wysłać innego niż xml, zawierającego z góry określoną strukturę to po co w ogóle jestem pytany o tą datę? Walidacja formularza nie pozwoli mi wysłać dokumentu z inną datą. W mojej ocenie najlepszy był by krok pierwszy – określ rodzaj dokumentu, a potem wyświetlenie pól koniecznych do uzupełnienia ręcznie których system nie może rozpoznać.

To o czym tu piszę nie jest dużą zmianą, ale zmiana ta, może ułatwić życie setkom tysięcy przedsiębiorców – jest warta zrobienia.

Kolejny CRASH po zapisie

Po poprawieniu daty, klikam zapisz i ponownie formularz od nowa jest analizowany przez procesy na backendzie, i ostatecznie psuje się :

Dlaczego warto wprowadzić zmiany UX’owe

Zmiana uxowa – postaci walidacji to nie tylko robienie „dobrze” użytkownikowi. W tym przypadku kolejne wprowadzenie danych powoduje uruchomienie zasobożernego procesu ponownej analizy dokumentu. Ponieważ dokument ten już przecież już został przeanalizowany i wskaliśmy użytkownikowi błędy w formularzu.

To też jest świetne miejsce na wydzielenie mikroserwów uruchamianych równolegle gdy ruch staje się większy niż zwykle. Bo przecież wystarczy teraz przeliczyć ilu przedsiębiorców popełnia ten błąd w trakcie składania dokumentów. Mały proces walidacji przemnożony przez parędziesiąt tysięcy użytkowników w jednym czasie robi różnice w zużyciu mocy obliczeniowej serwerów.

Czy droższy jest dobry UX (jego wdrożenie które skróci czas obecności użytkownika na stronie portalu) czy utrzymanie zespołu devops, który analizuje dlaczego całość systemu się rozpadła. Przy systemach obsługujących duże ilości użytkowników warto to obliczyć. Z mojego doświadczenia dobry UX jest tańszy niż walka z infrastruktura post factum.

Tworzenie aplikacji internetowych jest trudne, ale zastanawiam się czy osoby zlecające napisanie systemu, ogłaszające przetarg myślały o tym jak, nieprawidłowo działający system obciąża przedsiębiorców. Godziny czasu zmarnowane na walkę z systemem który nie generuje żadnej wartości, za który muszą zapłacić przedsiębiorcy to po prostu nie fair.

Architektura aplikacji – monolityczna / mikroserwisowa

Wobec problemów których doświadczam na tej stronie – zakładam, że po stronie serwisu KRS mamy do czynienia z architekturą monolityczna. Monolityczna architektura jest prostsza w uruchomieniu, niestety trudniejsza w skalowaniu. Dla wielu początkujących projektów zanim potwierdzą swoją wartość biznesowa jest słusznym pierwszym wyborem.

Jednakże gdy mamy do czynienia z serwisami których ilość użytkowników w krótkim okienku czasowym może być bardzo duża. Dlatego lepszym rozwiązaniem w tym wypadku jest zastosowanie tzw. mikro serwisów. W trakcie awarii takiej jak ta, gdzie potrzebujemy przyjąć duże ilości danych konieczne jest zastosowanie load balancerów. Warto też rozważyć użycie systemów kolejkowych które przyjmą dane i pozwolą obsłużyć je z opóźnieniem, nie blokując użytkownika. Dodatkowo loadbalancery rozdystrybuują ruch na wiele mniejszych serwerów, zapewaniając płynność działania serwerów.

Serwery te mogą być uruchamiane dynamicznie w oparciu o infrastrukturę chmurową i ilość przychodzących żądań od użytkowników. Tak by przyjąć pik danych, a po jego przetworzeniu nie generować kosztów związanych z ich utrzymaniem i zostać „zutylizowanym” przez mechanizm chmurowy. Obecnie każdy z dostawców chmurowych oferuje takie rozwiązania.

Rządowe musi być bezpieczne – tworzenie aplikacji internetowych dla instytucji nie jest proste

Ale skoro serwis jest serwisem rządowym, być może przykaz jest taki by całość była hostowana wyłącznie w Polsce. Ten scenariusz oznaczał by w praktyce konieczność stworzenia własnego centrum kolokacji serwerów, z zespołem specjalistów najlepiej zreplikowany w kilku niezależnych lokalizacjach w Polsce. Każdy inny scenariusz naraża nas na niebezpieczeństwo dostępu do tych danych przez inne kraje etc.

Tylko czy KRS ma wrażliwe dane?

Wydaje się, że wszystkie dane jakie wysyłamy do KRS to dane które finalnie ulegają upublicznieniu. Zatem posiłkowanie się infrastrukturą serwerową gigantów (AWS, AZURE, GC, etc) może być najbardziej ekonomicznym rozwiązaniem. Rozwiązanie, które pozwoli przedsiębiorcom wykonać ich ustawowy obowiązek bez dodatkowych kosztów w postaci „oczekiwania i sprawdzania” czy system działa już prawidłowo. Nie mówiąc już o stresie z tym związanym.

Jak poprawić system?

Trzymam kciuki za zespół IT obsługujący KRS, na pewno da się znaleźć jakieś rozwiązanie.