Sytuacja wyjściowa
Klient prowadził firmę usługową i zarządzał nią przez system zbudowany na platformie klasy no-code/low-code (Studio Manager). System obsługiwał harmonogramy, rozliczenia pracowników, płatności i powiadomienia. Na papierze wszystko działało. W praktyce — system generował problemy, których twórcy platformy nie potrafili rozwiązać.
Problem
Klient zgłosił się z jednym bugiem: „pracownicy mogą wypłacić pensję kilka razy". Po audycie okazało się, że to wierzchołek góry lodowej.
- Wypłaty bez kontroli: System generował potwierdzenie wypłaty i przenosił ją do historii, ale nie zerował salda pracownika. Kliknięcie „Wypłać" po raz drugi — system pozwalał.
- OAuth bez weryfikacji: Logowanie przez Google dawało natychmiastowy dostęp do systemu. Żadnej poczekalni, żadnego potwierdzenia admina. Ktokolwiek mógł wejść.
- Telegram odcięty: Wbudowany middleware platformy blokował webhooks z API Telegrama (niestandardowa struktura payloadu). Firma straciła powiadomienia.
- Podwójne opłaty: Algorytm naliczający dzienne opłaty (Tax/Restaurant) dublował koszty przy specyficznych kombinacjach dat — klasyczny edge case, którego testy manualne nie wyłapały.
Diagnoza
Zacząłem od audytu kodu i flow danych w systemie. Platforma no-code ograniczała dostęp do „surowego" kodu, więc musiałem odtwarzać logikę z konfiguracji wizualnej i logów. Kluczowe było zrozumienie, gdzie platforma kończy się, a gdzie zaczyna potrzeba prawdziwej inżynierii.
W przypadku Telegrama — testowałem API „na surowo" (curl + Postman), żeby udowodnić, że problem leży w middleware platformy, nie w API Telegrama.
Rozwiązanie
1. Atomowe wypłaty
Przepisałem logikę wypłat tak, żeby zerowanie salda i tworzenie rekordu historii odbywały się w jednej transakcji bazodanowej. Jeśli którykolwiek krok się nie powiedzie — cała operacja się cofa. Brak możliwości podwójnej wypłaty.
2. Zewnętrzny mikroserwis na Deno Deploy
Zamiast walczyć z ograniczeniami middleware platformy, zbudowałem lekki mikroserwis na Deno Deploy, który przyjmuje webhooks z Telegrama, waliduje payload i przekazuje dane do systemu w formacie, który platforma akceptuje. Niezależny, bezserwerowy, zerowy koszt utrzymania.
3. RBAC — 3-poziomowa kontrola dostępu
Wdrożyłem mechanizm: nowy użytkownik → poczekalnia → weryfikacja admina → przypisanie roli → dostęp.
Trzy stany: pending, verified, active.
Żaden użytkownik nie wchodzi do systemu bez świadomej decyzji admina.
4. Przepisanie logiki transakcyjnej
Całkowite przepisanie algorytmu naliczania opłat dziennych. Dodałem mechanizmy zapobiegające podwójnemu naliczaniu (idempotency check na kombinacji data + typ + pracownik) plus panel audytowy, gdzie właściciel widzi każdą operację z timestampem i źródłem.
Efekt
System działa stabilnie od wdrożenia. Właściciel ma pełną kontrolę nad dostępem, wypłatami i opłatami. Telegram znowu wysyła powiadomienia. Panel audytowy daje przejrzystość, której wcześniej brakowało.
Wnioski
Platformy no-code świetnie nadają się do szybkiego prototypowania. Ale gdy system zaczyna obsługiwać realne pieniądze, dane osobowe i procesy bezpieczeństwa — potrzebujesz inżyniera, który rozumie, co dzieje się „pod maską".
Nie chodzi o to, żeby wyrzucić no-code. Chodzi o to, żeby wiedzieć, gdzie kończy się „wyklikiwanie", a zaczyna inżynieria.