Z jakich warstw składa się aplikacja dla firmy i co robi każda z nich?

Cztery warstwy — co robi każda z nich?

Aplikacja dla firmy w pierwszej wersji ma cztery warstwy, nie kilkanaście modułów. Front, czyli to, co widzi użytkownik. Logika po stronie serwera w funkcjach brzegowych. Jedna baza Postgres z politykami dostępu na poziomie wierszy. Usługi zewnętrzne: płatności, poczta, SMS, modele AI.

Front to strony sprzedażowe, panel klienta i panel administratora. Pierwsza wersja zawiera zwykle logowanie i konta, jedną funkcję główną oraz jedną albo dwie wspierające, płatności, stronę zapisu pod markę klienta, automatyzacje i statystyki. Front niczego nie rozstrzyga o pieniądzach — pokazuje dane i przyjmuje decyzje użytkownika.

Druga warstwa to logika po stronie serwera, u nas w postaci funkcji brzegowych: odbiór powiadomień od operatora płatności, integracje, wysyłki, zadania cykliczne. Tam zostają klucze do usług, których nie wolno pokazywać w przeglądarce. Konfigurację produkcyjną trzymamy w ustawieniach dostawcy, nigdy w repozytorium kodu.

Trzecia warstwa to jedna baza Postgres z politykami dostępu na poziomie wierszy i wbudowanym logowaniem użytkowników. Baza rozstrzyga, kto które wiersze widzi — nie front i nie kod ekranu. To jedyne miejsce, w którym uprawnienia da się wyegzekwować.

Ma to konsekwencję, która zaskakuje przy pierwszej dłuższej liście. Domyślne ustawienie api.max_rows w konfiguracji Supabase to 1 000 wierszy (dokumentacja, odczyt 31 sierpnia 2026), a sam PostgREST nie ogranicza niczego — jego db-max-rows ma domyślnie wartość nieskończoną. Limit stawia dostawca, więc pobranie „wszystkich” rekordów cicho się ucina.

Czwarta warstwa to usługi, których nie ma sensu pisać samodzielnie: operator płatności, poczta transakcyjna, bramka SMS, modele AI przez API. Obowiązuje przy nich zasada, od której nie robimy wyjątków: powiadomienie od operatora płatności jest jedynym źródłem prawdy o wpłacie. Kwota i status zapisują się z tego powiadomienia, nie z przekierowania po zapłacie.

Podział na te cztery warstwy nie jest teorią z diagramu: tak zbudowanych jest kilkanaście aplikacji i serwisów, które utrzymujemy na co dzień. Skala, przy której ten układ się broni, to setki kont w aplikacji B2B i tysiące wizyt miesięcznie na serwis (stan: sierpień 2026).

Dlaczego jedna baza, a nie kilka osobnych usług?

Bo do skali tysięcy kont rozdzielenie kosztuje więcej, niż daje. Jedna baza to jedna kopia zapasowa, jeden model uprawnień i jedno miejsce, w którym sprawdza się spójność danych. Każda kolejna usługa z własnym magazynem dokłada pracę, której nie widać w wycenie: synchronizację i rozjazd stanów.

Alternatywy wyglądają rozsądnie na diagramie. Osobna baza dla rozliczeń, osobna dla katalogu, integrator sklejający całość. W praktyce to trzy zestawy uprawnień, trzy kopie do testowania i pytanie, która wersja rekordu jest prawdziwa, gdy dwie usługi zapiszą go w tej samej sekundzie.

Kiedy zmienić tę decyzję? Gdy pomiar pokazuje, że baza czeka na zasoby, a nie na sieć, albo gdy nad aplikacją pracuje tyle osób, że blokują sobie nawzajem zmiany w schemacie. Jedno i drugie widać w liczbach, zanim stanie się awarią.

Jedna baza ma jeszcze jedną zaletę, o której łatwo zapomnieć przy rysowaniu architektury: kopia zapasowa jest jedna i da się ją odtworzyć w całości. Kopie sprawdzamy odtworzeniem, nie obecnością pliku.

Co zmienia skala: 10, 1 000 i 10 000 użytkowników?

Zmienia trzy rzeczy, w innej kolejności, niż podpowiada intuicja. Z darmowych planów pierwsza wychodzi zwykle nie baza, tylko poczta. A pierwszą przeszkodą bywa regulamin hostingu, nie jego limity techniczne.

Przy dziesięciu kontach pilotażowych limity są bez znaczenia. Znaczenie ma zapis, który firmy pomijają: plan Hobby w Vercel jest zastrzeżony do użytku niekomercyjnego, a każde zastosowanie komercyjne wymaga planu Pro albo Enterprise (wytyczne fair use, odczyt 31 sierpnia 2026). Aplikacja, która przyjmuje płatności, jest zastosowaniem komercyjnym od pierwszego dnia.

Przy tysiącu kont kończy się poczta. Darmowy plan Resend to 3 000 wiadomości miesięcznie i 100 dziennie (cennik, odczyt 31 sierpnia 2026). Jedno powiadomienie wysłane do tysiąca kont w ciągu jednego dnia przekracza limit dzienny dziesięciokrotnie.

Rozmiaru bazy nie szacujemy z liczby kont. 500 MB w darmowym planie Supabase to limit rozmiaru bazy, a nie obietnica, że zmieści się w nim tysiąc firm z historią. Tę wartość odczytuje się z panelu dostawcy w konkretnej aplikacji i dopiero wtedy planuje plan płatny.

Przy dziesięciu tysiącach kont zaczyna się rachunek za nadwyżki. Plan Pro Supabase kosztuje od 25 USD miesięcznie i zawiera 8 GB dysku (potem 0,125 USD za GB), 250 GB transferu wychodzącego (potem 0,09 USD za GB) oraz 100 000 aktywnych użytkowników miesięcznie (cennik, odczyt 31 sierpnia 2026).

Dopiero w tym miejscu pomiar może uzasadnić piątą warstwę: kolejkę zadań albo cache. Wcześniej jedna baza z sensownymi indeksami i jawnym stronicowaniem obsługuje ten ruch. Ile taka aplikacja kosztuje w rachunku trzyletnim, liczy inny serwis: ile realnie kosztuje aplikacja w trzy lata.

Czego w pierwszej wersji nie budujemy?

Pięciu rzeczy, z których każda wygląda na „zróbmy od razu”, a każda dokłada warstwę do utrzymania i drugie miejsce, w którym coś może zniknąć.

• Kolejki zadań — dopóki wysyłki mieszczą się w czasie działania funkcji, kolejka dokłada tylko drugi magazyn stanu.
• Cache — to drugie źródło prawdy. Wchodzi, gdy pomiar wskaże zapytanie, które realnie boli; wcześniej ukrywa błędy w zapytaniach.
• Mikroserwisy — dzielą jeden problem na kilka, a każdy dostaje własne uprawnienia, własne wdrożenie i własną kopię zapasową.
• Własny serwer poczty — dostarczalność zależy od reputacji adresu IP i konfiguracji domeny; to praca na lata, nie na tydzień.
• Własne logowanie — reset hasła, blokady, drugi składnik, sesje. Mechanizm wbudowany w bazę robi to samo i jest sprawdzony szerzej niż jakikolwiek kod pisany na jeden projekt.

Płatności są osobnym przypadkiem: nie budujemy ich sami, ale też nie odkładamy na koniec. Testujemy je w trybie testowym operatora i sprawdzamy, co zapisało powiadomienie o wpłacie, zanim aplikacja zacznie przyjmować pieniądze. Który operator ma sens w pierwszej wersji, rozstrzyga porównanie płatności w MVP.

Po czym poznać, że warstwy są ustawione dobrze?

Pięć pytań, które właściciel firmy może zadać bez znajomości kodu. Odpowiedź „sprawdzimy” na którekolwiek z nich znaczy, że warstwa nie jest gotowa.

• Czy wpłata zapisuje się z powiadomienia operatora, a nie z powrotu użytkownika na stronę?
• Czy po wylogowaniu link do rekordu innego użytkownika przestaje działać?
• Czy listy w panelu mają jawne stronicowanie, czy ucinają się po 1 000 wierszy bez komunikatu?
• Kiedy odtworzono kopię zapasową po raz ostatni i ile to trwało?
• Czy klucze do usług zewnętrznych są w ustawieniach dostawcy, a nie w repozytorium kodu?

Wszystkie pięć pytań dotyczy styków między warstwami. Najdroższe awarie nie zdarzają się w środku warstwy, tylko na granicy: front zalicza płatność, której baza nie widzi, funkcja wysyła wiadomość, którą operator odrzucił. Co z tego wynika dla zabezpieczeń, zbieramy w dziale Jak nie zgubić danych i pieniędzy.