Jaki backend dla SaaS: Next.js, Postgres i kiedy potrzeba czegoś więcej
Aplikacje webowe
Jaki backend dla SaaS: Next.js, Postgres i kiedy potrzeba czegoś więcej
Praktyczny przewodnik po architekturze backendu SaaS: kiedy wystarczy aplikacja full-stack w Next.js z PostgreSQL, jak obsłużyć logowanie, płatności, zadania w tle, pliki i wielu klientów oraz kiedy dzielić system na usługi.
W skrócie
Praktyczny przewodnik po architekturze backendu SaaS: kiedy wystarczy aplikacja full-stack w Next.js z PostgreSQL, jak obsłużyć logowanie, płatności, zadania w tle, pliki i wielu klientów oraz kiedy dzielić system na usługi.
Dla większości nowych produktów SaaS właściwym backendem jest jedna aplikacja full-stack (np. Next.js z server actions lub API routes), baza PostgreSQL, worker do zadań w tle, gotowe logowanie i Stripe do płatności. Szybko się go buduje, łatwo utrzymuje i skaluje się dalej, niż potrzebuje większość produktów. Na osobne usługi dziel system dopiero wtedy, gdy konkretna część ma zupełnie inne obciążenie, zespół albo wymagania niezawodności.
Zespoły często przekombinowują backend nowego produktu: mikroserwisy, kilka baz i brokery wiadomości przed pierwszym płacącym klientem. To spowalnia rozwój i dokłada pracy operacyjnej bez wartości. Ten poradnik opisuje decyzje, które mają znaczenie, i kolejność, w jakiej je podejmować.
Domyślna architektura
Warstwa
Domyślny wybór
Dlaczego
Aplikacja i API
Next.js (lub inny framework full-stack)
Jeden kod dla strony marketingowej, aplikacji i API
Baza danych
PostgreSQL
Niezawodna, relacyjna, obsługuje JSON, wyszukiwanie i kolejki zadań
Dostęp do danych
ORM lub query builder (Prisma, Drizzle)
Typowane zapytania i migracje
Logowanie
Auth.js lub zewnętrzny dostawca
Bezpieczne logowanie bez budowania od zera
Płatności
Stripe
Subskrypcje, faktury, podatki i webhooki
Praca w tle
Kolejka zadań i proces workera
Długie zadania, ponowienia, harmonogramy
Pliki
Object storage (zgodny z S3, np. Cloudflare R2)
Wgrywane i generowane pliki
E-mail
Dostawca maili transakcyjnych
Rejestracja, reset hasła, powiadomienia
Monitoring
Śledzenie błędów i logi
Wiedza o problemach, zanim zgłoszą je użytkownicy
To bardzo blisko tego, czego użyliśmy w Ecomtoro: Next.js, PostgreSQL z Prisma, Auth.js, Stripe i kolejka zadań w Postgresie z osobnym workerem.
Dlaczego PostgreSQL to zwykle dobra baza
Dane relacyjne pasują do większości SaaS: użytkownicy, konta, projekty, faktury, uprawnienia.
Kolumny JSON obsłużą elastyczne dane bez drugiej bazy.
Wyszukiwanie pełnotekstowe pokrywa wiele potrzeb, zanim będziesz potrzebować wyszukiwarki.
Transakcje trzymają spójność danych o płatnościach i użyciu.
Kolejki zadań mogą działać w Postgresie, więc na start unikasz kolejnego systemu.
Korzystaj z zarządzanej usługi Postgres z automatycznymi kopiami i odtwarzaniem do punktu w czasie. Twoje dane to Twój biznes.
Wielu klientów w jednym systemie: zdecyduj wcześnie
Większość produktów B2B SaaS obsługuje wiele firm z jednego systemu. Najprostszy bezpieczny wzorzec to wspólna baza, w której każdy wiersz należy do konta (account_id), a każde zapytanie po nim filtruje. Wymuszaj to w jednym miejscu kodu, a nie ręcznie w każdym zapytaniu. Row-level security w Postgresie może dodać drugą warstwę ochrony.
Osobne bazy dla klientów mają sens tylko przy ostrych wymogach zgodności albo bardzo dużych klientach.
Logowanie i uprawnienia
Używaj sprawdzonej biblioteki lub dostawcy logowania. Nie pisz sam hashowania haseł ani obsługi sesji.
Obsłuż e-mail i co najmniej jedno logowanie społecznościowe lub SSO, jeśli klienci tego oczekują.
Na początku modeluj role prosto: właściciel, administrator, członek.
Sprawdzaj uprawnienia na serwerze przy każdej akcji, nigdy tylko w interfejsie.
Płatności to funkcja backendu
Stripe obsługuje płatności, ale backend musi wiedzieć, co wolno każdemu kontu:
Zapisuj plan i status z webhooków Stripe we własnej bazie
Wymuszaj limity (licencje, projekty, użycie) na serwerze
Obsłuż nieudane płatności, okresy karencji i rezygnacje
Rób obsługę webhooków idempotentną, żeby powtórzone zdarzenia nie liczyły się podwójnie
Zadania w tle: tu chowa się większość złożoności
Wszystko, co wolne, zaplanowane albo zawodne, powinno działać poza żądaniem webowym:
Przetwarzanie AI i analizy
Importy i eksporty
Wysyłka maili w paczkach
Synchronizacja z zewnętrznymi API
Nocne raporty i porządki
Kolejka zadań daje ponowienia, harmonogramy i podgląd. Osobny proces workera sprawia, że wolne zadanie nigdy nie spowalnia aplikacji. Pokazuj użytkownikowi postęp i powiadamiaj go, gdy praca się skończy.
API i integracje
Jeśli klienci lub partnerzy będą łączyć się z Twoim produktem, od początku zaprojektuj czyste API: wersjonowane ścieżki, klucze API lub OAuth, limity zapytań i dobre komunikaty błędów. Jeśli asystenci AI są częścią pracy Twoich użytkowników, rozważ serwer MCP, żeby narzędzia takie jak Claude i ChatGPT mogły korzystać z produktu bezpośrednio. Wzorce integracji opisujemy w tekście o integracji płatności, CRM i księgowości.
Podstawy bezpieczeństwa
Waliduj wszystkie dane wejściowe na serwerze
Trzymaj sekrety w zmiennych środowiskowych lub menedżerze sekretów, nigdy w kodzie
HTTPS wszędzie i bezpieczne ciasteczka
Zapisuj dostęp do wrażliwych danych
Aktualizuj zależności
Rób kopie bazy i testuj ich odtwarzanie
Kiedy potrzebujesz więcej niż domyślny zestaw
Wydzielaj osobną usługę lub dokładaj infrastrukturę, gdy jest konkretny powód:
Sygnał
Co dodać
Wyszukiwanie w milionach rekordów ze złożonym rankingiem
Dedykowana wyszukiwarka
Bardzo duży zapis zdarzeń lub analityki
Osobny magazyn analityczny
Współpraca w czasie rzeczywistym dla wielu użytkowników
WebSockety lub usługa real-time
Ciężka część przetwarzania z własnymi potrzebami skalowania
Osobna usługa workera
Kilka zespołów pracujących nad wyraźnie oddzielnymi obszarami
Osobne usługi z jasnymi kontraktami
Ścisłe wymogi lokalizacji danych dla klienta
Osobne wdrożenia lub bazy
Do tego czasu dobrze zbudowana jedna aplikacja jest łatwiejsza do zmian, testów i utrzymania.
Hosting
Jedna aplikacja z workerem i zarządzaną bazą zadziała na prostej platformie kontenerowej albo na VPS z Dockerem. Wybieraj według umiejętności zespołu i potrzeb wsparcia. Najważniejsze są automatyczne wdrożenia, kopie zapasowe, monitoring i możliwość cofnięcia zmian.
