Byłoby doskonale, gdyby nasze aplikacje zawsze działały tak, jak chcemy. Niestety, systemy są przewrotne i potrafią zadziałać nieoczekiwanie w najmniej spodziewanym momencie. Bez dopracowanego monitoringu i jednoznacznych wskaźników trudno wskazać źródło problemu. Dlaczego dobry monitoring ostrzeże nas szybciej niż klient i czego unikać, żeby klientowi nie odpowiedzieć "u mnie działa" - opowiem na prelekcji :) 

"Po ich owocach ich poznacie", powiada Pismo. Natomiast kod powiada: "po ich danych ich poznacie". Jedną ze szkół zapoznawania się z systemem jest długie i namiętne czytanie dokumentacji, przerywane rzucaniem okiem do kodu. Inną szkołą jest zanurkowanie w model danych (często w bazie) i posurfowanie po interfejsie użyszkodnika. Są to dwa naturalne końce systemu, legendarne wejście i wyjście. Poprzez oglądanie stanu tychże końców można sprawdzić, czy w środku jest zdrowe trawienie, czy niezdrowy proces gnilny. Wnikliwa egzaminacja pozwala stwierdzić obecność "DDDozy pospolitej", "stringozy złośliwej", "biegunki regexowej" czy też "syndromu nie-zrobione-u-nas". Niestety, czasem do infekcji dochodzi już na etapie życia płodowego programisty (czytaj: w szkole). Zapraszam na kurację. Przeczyszczającą. (Czyli naturalny ciąg dalszy "Passwords. Do you keep them safe?")

Web services development, no matter SOAP, REST, or RPC, is today as easy as adding an annotation to a method. Little more is required to create API using OAS (Swagger). But how to create the complex yet simple interfaces and provide reliable and consistent access to a wide variety of APIs, e.g. microservices? How to make a friendly system for both developers and consumers (web, mobile, fridge)? And how to prevent duplication of cross-cutting concerns (security, network, and others)? I will acquaint you with the possibilities, strengths and drawbacks of open source solutions. I will also show how to adjust them to own needs, what to take into consideration, and how to develop own API Gateway.