Wpis z mikrobloga

Napisałem aplikację konsolową do uzyskania kontroli nad niesfornym JSON-em

Znowu zmienił się JSON i nic nie działa? Teraz jest szybkie rozwiązanie! Wklej URL endpointa do pliku i odpal Breaker config.txt save. Następnym razem będziesz wiedział/a!

Jeśli pracowałeś/aś kiedyś z API to wiesz, jak irytujące jest debugowanie aplikacji. Tj. trzeba ustalić na początku czy to wina frontu, czy backendu, a dopiero później odpowiednia osoba może się tym zająć. Czasem to zadanie spada na frontendowca, ponieważ to we froncie objawiają się błędy backendu/API.

Często problemy sprawia nie tyle to, że backend nagle się zepsuł. Ale to, że ktoś stwierdził w backendzie, że trzeba zmienić nazwę parametru, albo poprawić styl, albo w ogóle usunąć jakiś parametr, bo niepotrzebny...

W efekcie na żmudne sprawdzanie kodu można spędzić kilkanaście godzin w ciągu roku.

Rozwiązań jest wiele. Jednym z takich rozwiązań jest pisanie testów i dokumentacji :). No ale nie zawsze masz na tym kontrolę. A pisanie testów endpointów we frontendzie jest też rozwiązaniem, ale jest czasochłonne i żmudne (ale wykonalne i najlepsze).

W każdym bądź razie ja poszukiwałem rozwiązania, które by było szybsze. Postawiłem przed rozwiązaniem kilka wymagań:

1. To ma być aplikacja konsolowa, żeby móc to sobie później gdzieś zintegrować
2. Aplikacja powinna umieć zapisać aktualny schemat endpointów, a później porównywać z nowym, by ustalić czy coś się zmieniło
3. Obsługa aplikacji powinna być ekstremalnie prosta i mało czasochłonna.

Przy tych założeniach napisałem prostą aplikację, której nadałem nazwę Breaker. Aplikacja ta przyjmuje 2 parametry. Pierwszy parametr to ścieżka do pliku konfiguracyjnego. W pliku konfiguracyjnym zapisujemy:

dfdsfdfdsfdsfsd
[http://google.com/jakiesapi/getSomething](http://google.com/jakiesapi/getSomething)
[http://google.com/jakiesinneapi/getCars](http://google.com/jakiesinneapi/getCars)
...

Pierwszy wiersz zawiera kod autoryzacyjny, który zostanie przekazany do API. Kolejne wiersze to endpointy. Aplikacja odpala kolejne endpointy. Jeśli podasz drugi argument w konsoli tj. "save", aplikacja pobierze dane z endpointów i zapisze schematy odpowiedzi do plików.

Teraz masz na dysku zapisane schematy wszystkich endpointów, które Cię interesują. I zostawiasz to tak. Za miesiąc dostajesz zgłoszenie, że coś nie działa w aplikacji.

Odpalasz jeszcze raz Breakera podając adres pliku konfiguracyjnego. Ewentualnie aktualizujesz kod autoryzacyjny. Tym razem jednak nie podajesz parametru "save". Aplikacja przechodzi znowu przez wszystkie endpointy i porównuje z zapisanymi wcześniej schematami. Jeśli zmieniła się nazwa pola, struktura, typ pola, cokolwiek w strukturze JSON-a, wyświetla się adres endpointa i stary i nowy schemat.

Już wiesz, co spowodowało problem.

Możesz też znowu zapisać nowy schemat podając parametr save. Dodatkowy każdy wynik działania aplikacji zapisywany jest do logu, do którego możesz się zawsze odnieść.

Chcesz odesłać raport do chłopaków od API? Masz gotowy log.

Aplikację znajdziesz na https://github.com/tomaszs/Breaker. Możesz pobrać kod na licencji MIT albo exe dla Windowsa w releases.

#programowanie #csharp #endpoint #backend #frontend #programista15k #git #github #json #tdd #dlaprogramistow
  • 8
@tomaszs: patrzac na twoje zdjecie to jeszcze pierwszego zarostu nie miales takze a jak to byla przenosnia do "mlodego" programisty to tym bardziej nie trafiles. Gdybys zadal pytanie gdzie robisz blad to moze i chcialoby mi sie odpisac i Ci wytlumaczyc ale skoro wybierasz droge brniecia w bledzie to nie przeszkadzam.
@bacteria: to zdjecie ma jakies 15 lat... No ale dobra. Pomine to ze Twoje komentarze to proba wywyzszenia sie kosztem kogos kogo uznales za zoltodzioba. Zalozmy hipotetyczna sytuacje:

Masz REST JSON API, na ktore nie masz wplywu, ale z ktorego korzystasz. API ma 230 endpointów. Do tego API nie ma Swaggera itp. W API dokonywane są zmiany i nie masz o nich informacji. Nie, nie mozesz zmienic API na inne. Chcesz