Czym jest aplikacja full-stack? Proste wyjaśnienie

Aplikacja full-stack to aplikacja, która zawiera wszystkie warstwy potrzebne do działania: frontend, który ludzie widzą i klikają, backend działający na serwerze i egzekwujący reguły oraz bazę danych, która pamięta wszystko. Lista zadań, która zapisuje Twoje zadania, pozwala zalogować się z dowolnego urządzenia i nie pokazuje Twojej listy nikomu innemu, jest full-stack. Pojedyncza strona pokazująca tylko godziny otwarcia nie jest.

„Stack” oznacza po prostu warstwy technologii ułożone jedna na drugiej. „Full” znaczy, że wszystkie są obecne.

Dlaczego to ma znaczenie, gdy budujesz z AI

Kiedy opisujesz aplikację kreatorowi AI, słowa, których używasz, decydują o tym, które warstwy zostaną zbudowane. „Zrób stronę, która pokazuje nasze menu” daje frontend. „Pozwól klientom zamawiać z naszego menu i pozwól kuchni widzieć nowe zamówienia” wymaga wszystkich trzech warstw, bo zamówienia muszą być zapisane, udostępnione dwóm rodzajom użytkowników i pozostać prywatne.

Znajomość tej różnicy pomaga na trzy sposoby:

• Prosisz o właściwą rzecz. Jeśli chcesz, żeby dane były zapisywane, powiedz to wprost. Kreator, który buduje tylko frontend, da wygląd gotowości, ale zapomni wszystko po odświeżeniu.
• Wychwytujesz pozorną kompletność. Demo z przykładowymi danymi może wyglądać identycznie jak działająca aplikacja. Znajomość warstw pozwala sprawdzić, czy dane naprawdę gdzieś trafiają.
• Rozumiesz koszty utrzymania. Sam frontend może być serwowany jako pliki statyczne. Backend i baza danych to programy działające na serwerach, skąd bierze się większość kosztów hostingu.

Codzienna analogia: restauracja

Pomyśl o restauracji.

• Sala jadalna to frontend. Menu, stoliki i notes kelnera. To, co widzą goście, i powinno być przyjemne oraz łatwe w użyciu.
• Kuchnia to backend. Goście do niej nie wchodzą. Przyjmuje zamówienia, sprawdza, czy danie jest dostępne, gotuje je i odmawia dziwnych próśb. Reguły znajdują się tutaj.
• Spiżarnia i księga zamówień to baza danych. Trzymają to, co istnieje i co zamówiono, dzięki czemu nic nie ginie przy zmianie zmiany.

Restauracja z samą salą jadalną może pokazać ładne menu, ale nie nakarmi. To aplikacja tylko frontendowa udająca full-stack.

Trzy warstwy szczegółowo

Warstwy komunikują się w ustalonej kolejności. Frontend prosi backend o coś przez API — zdefiniowany zestaw żądań, które backend przyjmuje. Backend sprawdza żądanie, czyta lub zapisuje bazę danych i odsyła odpowiedź. Frontend nigdy nie rozmawia z bazą bezpośrednio.

Ten porządek to najważniejsza zasada bezpieczeństwa w całym stosie. Wszystko, co jest we frontendzie, można odczytać i zmienić, bo działa na urządzeniu odwiedzającego. Dlatego reguły — „tylko właściciel może zobaczyć tę fakturę”, „kupon można użyć raz” — muszą być egzekwowane w backendzie. Więcej o podziale znajdziesz w frontend kontra backend.

Przykład krok po kroku: aplikacja do zapisów na zajęcia

Powiedzmy, że prowadzisz studio jogi i chcesz, żeby ludzie zapisywali się na zajęcia online.

Co robi odwiedzający: otwiera stronę, widzi grafik zajęć na ten tydzień, klika jedne, loguje się i rezerwuje miejsce.

Co dzieje się pod spodem:

1. Frontend pokazuje grafik. Żeby go wypełnić, pyta backend: „Jakie zajęcia są w tym tygodniu i ile miejsc zostało?”
2. Backend pyta bazę danych o zajęcia i liczy zapisy na każde z nich, po czym odpowiada.
3. Odwiedzający klika Zapisz się. Frontend wysyła „zapisz osobę zalogowaną na zajęcia 42”.
4. Backend sprawdza: czy ta osoba naprawdę jest zalogowana? Czy zajęcia są pełne? Czy już się zapisała? Dopiero gdy wszystko jest w porządku, zapisuje nowy wiersz rezerwacji w bazie danych.
5. Backend odpowiada „zapisano”, a frontend pokazuje potwierdzenie.
6. Później właścicielka studia loguje się i widzi listę zajęć. Backend sprawdza, czy jest administratorką, zanim pokaże imiona wszystkich uczestników.

Wyobraź sobie, że to zbudowano jako sam frontend. Grafik mógłby się wyświetlać, a przycisk Zapisz się pokazałby ładny znaczek, ale rezerwacja zniknęłaby po odświeżeniu, licznik „wolnych miejsc” byłby błędny dla wszystkich innych, a właścicielka nigdy by jej nie zobaczyła. Krok 4 — sprawdzenia — w ogóle by nie istniał. Na tym polega praktyczna różnica.

Najważniejsze pojęcia

• Frontend (strona klienta): część działająca w przeglądarce.
• Backend (strona serwera): część działająca na serwerze. Nazywany też serwerem API.
• Baza danych: miejsce, w którym dane są przechowywane w uporządkowany sposób. Zobacz czym jest baza danych.
• API: lista żądań, które backend przyjmuje od frontendu lub innych programów.
• Uwierzytelnianie: sprawdzenie, kim ktoś jest (logowanie). Autoryzacja: sprawdzenie, co wolno mu robić.
• Wdrożenie (deployment): umieszczenie wszystkich warstw na serwerach, aby mogła z nich korzystać publiczność.
• Monolit kontra usługi: jeden program robiący wszystko albo kilka mniejszych (na przykład strona i osobne API). Oba są full-stack.

Częste błędy i nieporozumienia

• „Wygląda na gotowe, więc jest gotowe”. Przykładowe dane i działający na oko przycisk to nie to samo co zapisane dane. Odśwież stronę, otwórz ją w oknie prywatnym i sprawdź, czy dane nadal są.
• Umieszczanie reguł we frontendzie. Ukrycie przycisku to nie bezpieczeństwo. Jeśli backend nie sprawdza, każdy, kto zna żądanie, może je wysłać.
• Umieszczanie sekretnych kluczy we frontendzie. Klucz dostawcy płatności lub AI w kodzie przeglądarki jest czytelny dla każdego odwiedzającego. Klucze należą do backendu, w zmiennych środowiskowych — zobacz zmienne środowiskowe i sekrety.
• Myślenie, że full-stack znaczy skomplikowany. Mała aplikacja full-stack może mieć kilka ekranów, garść tras backendu i trzy tabele w bazie. To opis warstw, a nie rozmiaru.
• Myślenie, że musisz sam wybrać każdą technologię. Każdy rozsądny, powszechnie używany stos wystarczy na pierwszą wersję. Ważniejszy jest jasny opis danych i reguł.

O co poprosić kreatora AI

Opisz aplikację przez trzy warstwy, nawet jeśli nie używasz ich nazw:

• Dane: „Zapisuj zajęcia (nazwa, czas, pojemność) i rezerwacje (zajęcia, osoba, czas zapisu) w bazie danych.”
• Reguły: „Nie można zapisać się na zajęcia powyżej pojemności. Osoba może zapisać się na zajęcia tylko raz. Tylko administratorzy widzą, kto się zapisał.”
• Ekrany: „Tygodniowy grafik, potwierdzenie zapisu, strona administratora z listą zapisów na każde zajęcia.”
• Sprawdzenia: „Egzekwuj te reguły na serwerze, nie tylko na stronie. Trzymaj klucze API na serwerze.”

Potem testuj jak sceptyk: odśwież, zaloguj się na dwie różne osoby, spróbuj zobaczyć dane, których nie powinieneś. Przewodnik po budowaniu aplikacji z AI pokazuje tę pętlę krok po kroku.

Aplikacje full-stack w Mythex

Mythex buduje aplikacje webowe full-stack na podstawie opisu w czacie. Domyślnie nowa aplikacja dostaje frontend w React i TypeScript; gdy aplikacja potrzebuje zapisywać dane, Mythex dodaje do projektu dedykowaną bazę Postgres, a na życzenie możesz dodać osobny serwer API (na przykład w Pythonie, Node, C# lub Javie) obok strony. Wszystko działa razem w podglądzie na żywo i jest publikowane pod publicznym adresem. Strona dokumentacji o aplikacjach wieloserwisowych pokazuje, jak strona i API są razem podglądane i publikowane, a strona kreatora aplikacji full-stack zawiera punkty startowe.

Pytania