Nowoczesny React: Deployment na Vercel
od Podstaw
5 godz. 59 min · ReactJS · Full-stack i Programowanie
Michał JabłońskiCzego się nauczysz
- Podstawy React jako biblioteki UI
- Konfiguracja środowiska programistycznego
- Składnia i reguły JSX
- Komponenty React jako podstawowe bloki aplikacji
- Przekazywanie danych przez props
- Renderowanie list i kolekcji
- Renderowanie warunkowe elementów
- Stylowanie komponentów i moduły CSS
- Zarządzanie stanem aplikacji
- Hook useState do przechowywania danych
- Hook useEffect do efektów ubocznych
- Routing i nawigacja w aplikacji SPA
- Parametry dynamiczne w adresach URL
- Obsługa formularzy i walidacja danych
- Integracja z biblioteką Formik
- Komunikacja z API backendowym
- Obsługa operacji asynchronicznych
- Zarządzanie stanem ładowania i błędów
- Narzędzia deweloperskie do debugowania
- Konfiguracja środowiska produkcyjnego
- Deploy aplikacji na platformie hostingowej
Nowoczesny React
React przeszedł długą ścieżkę rozwoju i część z jego funkcjonalności nie są już powszechnie używane. Dlatego w tym kursie skupimy się na najnowszych technikach pracy z biblioteką - poznasz współczesne podejście do budowania komponentów z wykorzystaniem hooks (useState, useEffect), zrozumiesz zasady kompozycji i zarządzania stanem aplikacji. Pokażemy Ci też jak efektywnie korzystać z narzędzi deweloperskich, debugować kod i wdrażać aplikacje na produkcję z użyciem współczesnych platform jak Vercel.
Hooki
Hooki to fundament nowoczesnego Reacta, który całkowicie zmienił sposób tworzenia komponentów. W kursie nauczysz się efektywnie zarządzać stanem aplikacji używając useState, wykorzystywać useEffect do operacji lifecycle i side-effects, oraz poznasz reguły korzystania z hooków. Wszystko to przećwiczysz w praktycznych zadaniach, takich jak implementacja filtrowania listy elementów, gdzie zastosujesz zdobytą wiedzę w realnym scenariuszu.
Formularze
Obsługa formularzy to nieodłączny element każdej aplikacji webowej. Pokażemy Ci jak kontrolować wartości pól input, wykorzystać popularną bibliotekę Formik do zarządzania złożonymi formularzami oraz implementować walidację danych. Wiedza ta zostanie utrwalona poprzez praktyczne zadanie, w którym rozwiniesz formularz o dodatkowe pola i zastosujesz poznane techniki w rzeczywistym przypadku użycia.
Połączenie z back-endem
Większość aplikacji wymaga komunikacji z serwerem. Nauczysz się jak poprawnie wykonywać operacje asynchroniczne w komponentach React, obsługiwać stany ładowania i błędów, oraz efektywnie korzystać z klienta HTTP do zapytań AJAX. Zaczniesz od pracy z przygotowanym mockiem API, by następnie przejść do prawdziwej integracji z back-endem. W praktycznym zadaniu zaimplementujesz pełny przepływ danych - od pobrania, przez wyświetlenie, aż po wysłanie na serwer.
Deployment
Poza budową aplikacji React, w kursie znajdziesz także moduł poświęcony wdrażaniu aplikacji na produkcję. Poznasz prawidłową konfigurację serwera produkcyjnego dla architektury SPA, nauczysz się zarządzać zmiennymi środowiskowymi poprzez pliki .env oraz przeprowadzisz deployment na platformie Vercel. Dzięki temu Twoja aplikacja będzie nie tylko działać lokalnie, ale także będzie gotowa do użycia przez realnych użytkowników w internecie.
Dla kogo jest ten kurs?
Nowoczesny React stworzyliśmy z myślą o osobach, które chcą nauczyć się Reacta i jednocześnie znają JavaScript. Niezależnie od tego, czy React jest Twoim pierwszym frameworkiem, czy masz już doświadczenie w pracy np. ze Svelte czy Vue, ten materiał jest dla Ciebie. Wskazane jest również posiadanie ogólnej wiedzy na temat tworzenia interfejsów z HTML i CSS oraz obsługi narzędzi takich jak Git czy podstawy pracy z terminalem.
Nasza aplikacja w tej formie, którą już mamy, jest gotowa do tego, żebyśmy zrobili
tak zwany deployment, czyli żeby wypłynęła ona na szerokie wody, żebyśmy wreszcie
mogli zobaczyć ją na jakiejś domenie i pochwalić się przed nią znajomymi.
Jeśli chodzi o samą aplikację, możemy to zrobić za pomocą kilku różnych elementów.
Ten deployment może być przeprowadzony zauważ tutaj W Gajdzie mamy coś takiego
jak deploy, jest static site i tutaj mamy kilka różnych wariantów.
Deployment może być na Netfly, na weselu, na Cloudflare i tak dalej.
Mamy tutaj kilka wariantów.
My skorzystamy z wesela.
Chcę Ci pokazać wesela tutaj podczas tego szkolenia.
I pierwsze co musimy zrobić to zainstalować go, czyli globalnie
Instalujemy bibliotekę, która nazywa się Shell.
Zobaczmy sobie tutaj.
Uruchamiamy terminal i instalujemy tą bibliotekę.
Będziemy musieli rozważyć kilka rzeczy.
Tutaj zrobiliśmy sobie sztuczkę, żebyśmy mieli dostęp do tego backendu, który jest
zaprojektowany Projektowany lokalnie.
Docelowo nie może tak to pozostać.
Natomiast sam Wersal oferuje nam coś takiego jak serverless functions, więc
pokażę Ci w jaki sposób możemy ten backend, który mamy tutaj zamontowany,
faktycznie przesunąć sobie na samego Verla.
Dzięki użyciu właśnie serverless functions.
Teraz, żeby Wersal zadziałał, potrzebujesz wejść na jego stronę
i założyć sobie konto.
Ja założyłem sobie takie hobbystyczne konto.
Tam będzie pytanie czy konto jest pro czy hobby.
Można zaznaczyć sobie hobby i utworzyć konto.
Jeśli masz konto na GitHubie, możesz po prostu jako źródło logowania, jako sposób
logowania i rejestracji wybrać sobie po prostu GitHub i wtedy zarejestrować się
GitHub i połączyć sobie to konto z GitHub em.
Kiedy teraz będziemy sobie uruchamiać tą komendę, czyli zobacz, że
wszystko nam się zainstalowało.
Jeżeli uruchomię tą komendę to zauważ, że mam tu continue with GitHub
albo inne sposoby logowania.
Ja właśnie użyję to Continue it GitHub.
Czyli tak mam spiętego swojego wesela.
Musisz mieć oczywiście konto na weselu i dopiero wtedy wrócić tutaj sobie
zainstalować wesela i uruchamiając tą komendę połączyć to jeszcze raz, tak, żeby
on zorientował się, że właśnie ten projekt będzie na Twoim koncie, który jest
połączony z Twoim adresem mailowym.
Wrzucać mamy tutaj setup deploy i teraz możemy sobie to połączyć z Secret Giver.
Jeżeli po prostu klikniemy enter, to wszystkie te elementy, które proponuje nam
właśnie Sully będą jako domyślne, więc możemy to sobie zrobić w ten sposób.
Oczywiście chcę.
Michał Projects Nie chcę linkować z istniejącym projektem,
nie mam żadnych projektów.
Secret Giver to jest dobry pomysł na nazwę tego naszego projektu
Directory I could located.
Zauważ tutaj, że kod mamy wszędzie tak naprawdę, czyli w tym głównym katalogu,
więc to może jak najbardziej tak zostać.
Więc to proponowane przez Wersal jest ok i w tym momencie ten
projekt będzie uploadowany.
I jest takie podsumowanie.
I to jest dla nas najbardziej istotne, dlatego że jeżeli build command jest ok,
czyli jest git build, no on zauważ orientuje się, że korzystamy z gita,
orientuje się, że mamy tutaj właśnie w package do JSON te komendy i będzie ich
używał do deploymentu, więc wszystko co tutaj widzisz jest ok.
Niemniej ważny jest tutaj też output Directory i to Output Directory sugeruje
nam, że ten test będzie zaserwowany.
Czyli to będzie katalog, który po wybudowaniu będzie zaserwowany z rzeczami,
które mamy właśnie wystawione jako produkcja.
Widzimy, że to już nam się dobrze układa, dlatego, że to właśnie tam w liście
będziemy mieli produkcję, więc to Output directory jest jak najbardziej ok i te
wszystkie elementy i nie chcemy modyfikować tych settingów.
Dlatego tutaj domyślnie mieliśmy zaznaczone N, czyli no
tu są dwie ciekawe rzeczy.
Przede wszystkim to inspekt, które tutaj mamy.
To jest coś, co pozwala nam zobaczyć jak ten projekt się buduje, czyli w momencie,
w którym sobie to otworzymy, widzimy, że mamy status, gdzie nasz
projekt jest budowany.
Mamy environment production.
Widzimy tutaj screena z momentu, w którym już aplikacja jest wystawiona, czyli
widzimy, że wszystko jest ok, ale tutaj jak gdyby.
Request aborted.
Mamy chyba problem z połączeniem z backendem, co nie powinno nas dziwić.
Za chwilę sobie zobaczymy tą aplikację.
Tutaj masz cały build log, który pokazuje Ci, że właśnie wait build po prostu został
wykonany, tylko został wykonany już po stronie serwerowej, czyli
nie robiliśmy go lokalnie.
Zrobił to serwer deweloperski i bardzo ładnie wystawił nam to
wszystko i deployment summary.
Widzimy, że on się orientuje, że Mavita to jest jedna z takich cech, którą ma Wersal.
Informuje nas właśnie Wersal, że sam będzie starał się rozpoznawać
z jakiego rodzaju narzędzi korzystamy.
Więc tutaj Wita zna jak najbardziej.
Widzi, że mamy te statyczne assety, które trzeba wystawić i to
właśnie jest wystawione.
Co więcej, mamy tutaj dostęp do runtime loggs i możemy sobie
zobaczyć, co tam jest nie tak.
Gdybyśmy chcieli zobaczyć sobie tutaj połączenie z naszym serwerem, czyli w
momencie, w którym za chwilę sprawdzimy sobie ten projekt i zobaczymy, na jakiej
domenie on sobie tutaj wstał, czyli mamy tutaj to production deployment i tutaj
mamy domenę, w której jest Secret app, mamy loading people i mamy network error.
Zobaczmy sobie jak to będzie wyglądało w momencie, w którym podejrzymy sobie
co tam jest z networkiem nie tak.
Gdybyśmy jeszcze raz to sobie odświeżyli, no to oczywiście nie mamy wystawionego
naszego serwera, ale widzimy, że to People tutaj elegancko jakby uderza do portu
3000, Więc generalnie gdybyśmy sobie to ustawili, możemy właśnie pójść dość
naiwnie, że jeżeli sobie wystawimy właśnie backend, to wszystko będzie ok.
Czyli ja chciałbym sobie wystawić backend na localhost 3000 people, zobaczyć sobie,
czy to faktycznie mi się z tym backendem połączy.
Tutaj zauważ, mieliśmy problem z Error Connection i tutaj elegancko, jak
gdyby łączymy się z tym backendem.
Dzieje się tak dlatego, bo właśnie JSON Server daje nam Corsy, czyli Cross Origin
Resource sharing ustawiony na tak zwaną gwiazdkę, czyli akceptuje wszystko.
W takim wypadku zaakceptuje nam również właśnie z tej domeny request do backendu.
I mamy tutaj ten nasz backend.
Jednak docelowo nie chcemy tego tak zostawić, dlatego, że zauważ, że gdybyśmy
to zostawili w ten sposób, to wszystko nam tutaj fajnie działa.
Możemy sobie po prostu startować kolejne, kolejne imprezy i jest
ok, ale to będzie działało tylko u nas, tylko lokalnie.
Gdybyś Ty teraz wszedł na tą domenę, odwiedził ją sobie właśnie Secret
App, no to zauważymy, że to po prostu nie będzie działać.
Tutaj po prostu nie będziemy mieli tej listy ludzi, dlatego, że ona jest u mnie
tylko i wyłącznie dlatego, że lokalnie jak gdyby ta aplikacja właśnie jako client
łączy się do mojego serwera po localhost 3000.
Najpierw rozwiążmy sobie inny problem, czyli zauważmy, że moglibyśmy sprawdzić,
czy tutaj out of the box jesteśmy ustawieni jako single page application i
odświeżyć sobie tą stronę i zauważysz, że tutaj dostajemy charakterystyczny 404 not
found, co oznacza, że serwer HTTP, który jest tutaj ustawiony przez wesela on nie
ma domyślnie zapniętego single page application mode rewrite.
Żeby to zrobić polecam Ci otworzyć stronę Weight on Wersal.
Czyli tutaj w dokumentacji możemy sobie właśnie zobaczyć framework Wait.
I tutaj jeżeli będziemy mieli Wita to zauważymy, że Wersal do JSON potrzebujemy
czegoś takiego, żeby zrobić SPA, czyli potrzebujemy dodatkowego pliku.
Spróbujmy sobie to skopiować.
Potrzebujemy tutaj na szczycie w katalogu utworzyć sobie Wersal JSON.
Zauważ, że w momencie deploymentu tej naszej aplikacji dostaliśmy coś takiego,
że tutaj pojawił się katalog dot Wersal.
I tutaj będą informacje, takie metadane na temat naszego projektu, tak żeby
Wersal wiedział jak ma go deploować.
My skorzystaliśmy z deploymentu, który nie wymaga od nas połączenia z gitem.
Natomiast polecam Ci sprawdzić na celu właśnie połączenie z gitem, dlatego, że
tam będzie to fajnie wyglądać w kontekście właśnie puszczania zmian na Origina i
wtedy przebudowywania sobie tego, czyli robienia tak zwanego continuous
deployment Continuous delivery.
Zobaczmy sobie tutaj.
Jeżeli utworzymy nowy plik JSON i wrzucimy sobie tą konfigurację,
to to powinno już działać jako SPA.
Ale zauważ, że teraz wersja jeszcze nie wie, że ma to przebudować.
To nie jest tak, że dowolna zmiana w projekcie spowoduje, że ten projekt
produkcyjnie zostanie przebudowany.
Możemy sobie za każdym razem zobaczyć tutaj nasze deployment i to deployment
będzie symbolizowało moment, w którym faktycznie robimy deploy, czyli
przebudowujemy tą naszą produkcję, robimy coś nowego, Widzimy, że to się stało
6 minut temu i trwało 17 sekund.
W takim wypadku to jest ten nasz pierwszy build.
Chcemy zrobić kolejny.
Żeby zrobić kolejny kolejne, potrzebujemy polecenia i ono jest troszeczkę inne,
ale też korzystamy z wersji live.
Zobacz, że mamy tutaj deployment i Production Run Pro to override later
i dokładnie z tego chcemy skorzystać.
Czyli chcemy to polecenie wersję Pro i w momencie, w którym to uruchomimy on
powinien nam przebudować tą aplikację i jeżeli to zrobi, możemy sobie to
podejrzeć właśnie tutaj w Inspekt.
Ja sobie to otworzę od razu tutaj z deployment.
Zauważ, one się odświeżają i tutaj mamy production ready, czyli widzimy,
że został zrobiony deploy.
I teraz spróbujmy zrobić to samo, czyli add person.
Odświeżam sobie tutaj.
Zobaczmy czy spa działa.
Jest idealnie.
Mamy właśnie tą naszą architekturę SPA.
Czyli jak widzisz potwierdza się to, że każdy absolutnie serwer z domyślną
konfiguracją musi mieć tego modre Wrighta, niezależnie od tego czy byłby to enginex,
czy byłby to Apache czy jakiś inny serwer.
Tak jak tutaj, serwer Lowski będzie miał właśnie tego typu zapisy, które pozwolą
nam użyć właśnie rewrite na index HTML, czyli zrobienie faktycznie
tego single page application.
Jeśli nie znam danej ścieżki, po prostu odprowadzam Cię do index HTML.
Naprawmy sobie kolejną rzecz, czyli chcielibyśmy, żeby to people było
faktycznie dostępne, ale bez konieczności ustawiania tego serwera backendowego.
Zauważ, że tutaj mamy ten problem, który mieliśmy w And Dot Production, czyli
chcielibyśmy, żeby teraz Dot and i Dot Production różniły się od siebie i
faktycznie żebyśmy to serwowali z jakiegoś innego źródła, czyli produkcyjnie.
Chcemy, żeby to było zupełnie gdzie indziej.
Okazuje się, że Wersal oferuje nam jeszcze jedną bardzo fajną funkcjonalność,
którą są tak zwane serverless functions.
Te serverless functions możesz sobie doczytać tutaj w konfiguracji
frameworka Wid, sprawdzić je szerzej.
Natomiast zależy nam tu głównie na tym, żeby utworzyć sobie folder API i ten
folder API będzie odpowiadał strukturze właśnie takiej Restowej Backendowej.
Zobacz jak to działa.
Jest to fantastyczne, ponieważ działa to out of the box.
Nie musimy nic dodatkowego robić, tylko przygotować sobie po
prostu coś takiego jak API.
I teraz tutaj potrzebujemy sobie zrobić dokładnie taką nazwę pliku, gdzie będziemy
chcieli odczytywać tą naszą listę osób.
U nas było to people, więc robimy sobie plik people.
Musi być to plik javascriptowy.
I teraz jeżeli zrobimy export function gets no to właśnie to będzie symbolizowało
to, że będziemy chcieli zwrócić jakiś użytkowników i właśnie będziemy
używali tutaj metody Get.
Zauważ, że gdybyśmy sobie wrócili do naszych serwisów, to tutaj widzimy w
People serwis, że zwracamy się właśnie tutaj do People właśnie po Get i
podobnie będzie dla Post People.
Możemy sobie obydwa te elementy przygotować.
I teraz tutaj przygotujmy sobie dane.
Znowu wracamy do tego samego zapisu, to znaczy wracamy do momentu, w którym
chcielibyśmy mieć właśnie zapisane to w postaci tablicy zwykłej tablicy.
Ja sobie pożyczę.
Dwa imiona i spróbujmy sobie to zrobić właśnie w ten sposób,
czyli tutaj const people.
Zrobimy sobie właśnie taką tablicę i ta tablica będzie reprezentowała te
osoby, które chcemy dostarczyć.
I zobacz, że tutaj na returnie możemy sobie utworzyć tak zwany
new response response.
W tym wypadku jest to API, które już istnieje w przeglądarkach, czyli jak gdyby
response To jest konstruktor, który istnieje w Libdom.
Jesteśmy w stanie sobie zobaczyć jak on wygląda, poczytać o nim na MDN.
Polecam Ci odwiedzić to źródło, żeby zobaczyć sobie jak to działa.
Natomiast tutaj korzystamy z natywnych funkcjonalności przeglądarki,
czyli new response.
Możemy sobie zrobić w ten sposób i teraz zależy nam na tym, żeby people
było jako JSON stringify.
To jest ważne dlatego, że chcemy to przedstawić właśnie jako JSON.
Natomiast w poście tutaj rzecz jest o tyle bardziej skomplikowana, że musimy mieć
coś takiego jak request i request.
To jest to, co pozwala nam odczytać body, które zostaje wysyłane.
Jednak odczyt tego body będzie troszeczkę bardziej skomplikowany, dlatego, że musimy
asynchronicznie odczytać sobie to w postaci JSON.
To też jest natywny request, czyli mamy tutaj do czynienia z natywnym z kolei
requestem, jeśli chodzi o przeglądarkę i tutaj jesteśmy w stanie
odczytać sobie body.
Na razie nic z tym nie róbmy.
Na razie zróbmy sobie po prostu return response JSON stringify i zauważ, że to
jest na ten moment tylko zaślepka, żeby zobaczyć, czy ten post nam w ogóle
zadziała, czy tutaj zaślepimy sobie właśnie get i post.
Jeśli chodzi o People w tym układzie będziemy liczyli na to, że to people
będzie obsługiwało właśnie metodę Get i metodę Post i będziemy to
wszystko mieli tutaj rozwijane.
Natomiast ta wartość pomimo tego, że jest statyczna, to zauważ, że jesteśmy w stanie
jak gdyby dodawać tutaj elementy, ponieważ to będzie działało jako swego rodzaju
singleton, czyli będziemy mieli te dane dostępne w momencie, gdy wystawiony
zostanie endpoint people.
W tym układzie te dane będą czyszczone dopiero w momencie, gdy będziemy
robili kolejny deployment.
Czyli generalnie nie mamy tutaj twardego zapisu danych, bo nie możemy tego zapisać
sobie w bazie danych, ale okazuje się, że jest taka możliwość.
Gdybyśmy sobie podpięli jeszcze jedną funkcjonalność z wesela, o tym za chwilę.
Na razie tutaj ten stan jest ulotny, ale jest na tyle to dobrze przygotowane na ten
moment, że jesteśmy w stanie po pierwsze to przetestować, a po
drugie skorzystać z tego.
Jeśli chodzi o czas od jednego deploymentu do drugiego, wydaje mi
się, że to dość sensowne.
Gdybyśmy teraz chcieli sobie to poprawić, to pamiętaj o tym, że Endproduction
to już nie będzie localhost 3000.
Będziemy po prostu wchodzić na API, czyli będzie wystawione coś takiego jak API.
I to jest tak zwany reverse proxy, który jest z automatu ustawiony właśnie przez
wesela, Czyli to API będzie przerobione na serverless functions
i my będziemy w stanie do tego się dostać.
Więc tutaj n production sobie zmieniamy.
W PeopleJS jesteśmy gotowi do tego, żeby wysyłać people i żeby przyjmować body,
ale nic z tym tak naprawdę nie robimy.
Spróbujmy sobie teraz wykonać tą samą komendę, czyli Universal prod.
Przypominam Ci, że możemy podglądać ten deployment.
Możemy sobie zobaczyć jak on działa i sprawdzić sobie czy wszystko
przebiegło pomyślnie.
Tutaj też będziemy mieli podsumowanie na temat funkcji.
Zauważ, że teraz deployment summary oprócz static assetów, które mamy
wystawione, mamy też functions.
Widzimy, że mamy coś takiego jak API people, więc jak widzisz Wersal rozumie
to, że właśnie w tym katalogu API ma wystawić plik gdzie mamy peoples i
powinniśmy teraz otrzymać właśnie te nasze dane.
Dwóch użytkowników.
Zobacz, że jest Ewa, jest Mark.
Teraz gdybyśmy przejrzeli sobie to po networku, jeszcze raz odświeżyli, i
weszli na Exchange, później na People.
Zauważmy, że to działa i response, który tutaj dostajemy to faktycznie jest
response w postaci JSON, gdzie będziemy mieli tych dwóch użytkowników.
Teraz możemy tutaj sprawdzić sobie czy działa nam ad person, czyli
czy będzie działał post.
Spróbujmy sobie dopisać jednego użytkownika np.
Test I tutaj też to Michał Małpa. Ok.
Widzimy, że tutaj dostajemy 200$, czyli generalnie payload, który wysłaliśmy.
To jest właśnie email name i preview response, który dostajemy
to też jest name email.
Czyli generalnie wszystko działa poprawnie tak jak byśmy chcieli.
Natomiast nie zobaczymy oczywiście tej dodatkowej osoby tutaj, bo jeszcze nie
zaimplementowaliśmy tej funkcjonalności.
Zauważ, że teraz przy tej serverless Functions wracamy tak naprawdę do korzeni,
dlatego, że gdybyśmy chcieli to sobie przedstawić, to musielibyśmy sobie tutaj
w People dorzucić po prostu pushem.
Po pierwsze zauważ, że musimy nadać ID.
Spróbujmy to sobie zrobić.
Ja użyję do tego biblioteki, która nazywa się Nano ID i później wpiszmy sobie body.
Nie powinniśmy tego robić w ten sposób produkcyjnie.
Jeżeli chcesz rozwijać ten przykład, bawić się nim na dalszą metę, to pamiętaj o
tym, że to body powinniśmy zwalidować.
Czyli tutaj tak naprawdę powinniśmy wyciągnąć właśnie Neymara i na przykład
e-maila, którego chcemy mieć w tym body, tak żebyśmy byli w stanie
tutaj walidować sobie te dane.
Czyli generalnie powinniśmy tutaj zwracać błędy, również jeśli coś jest nie tak,
wtedy Response przyjąłby u nas zupełnie inny status.
Spróbujmy sobie teraz doinstalować jeszcze Nanoid do naszego projektu.
Nanoid pozwoli nam na generowanie ID ków.
Wystarczy, że sobie go zaimportujemy.
Teraz mamy tutaj import Nanoid from Nanoid i teraz people, które będziemy tutaj
mieli, powinno mieć tego nowego użytkownika, którego tutaj przesyłamy.
Zobacz, że to body jest spreparowany tutaj, więc w momencie, gdy wyślemy posta
jesteśmy w stanie to odczytać, a później rozkodować.
No i przechowując te dane jako JSON string i później wysyłamy to Get.
Jednak pamiętajmy o tym, że za każdym razem, jeżeli zrobimy teraz jakąkolwiek
zmianę, to musimy tutaj użyć sobie tej komendy sell prod.
Tak aby przebudować sobie tą naszą aplikację i dopiero wtedy
sprawdzić czy ona działa.
Docelowo polecam Ci zrobić jeszcze jedną rzecz.
Sprawdź wersję storage dlatego, że tutaj zauważysz, że jesteś w stanie właśnie tam
gdzie mamy tą serverless function, czyli tam gdzie mamy apipeople JS jesteśmy w
stanie wrzucić na przykład key value, czyli wersalke value.
To będzie taka baza danych redisowa, która pozwoli nam na to, żeby
odczytywać sobie wartości.
I tutaj na Quick Start zobaczysz sobie, że wystarczy doinstalować sobie do naszego
projektu coś takiego jak kV używając npm w naszym przypadku, czyli npm install kV i
wtedy możemy sobie tego użyć właśnie po to, żeby dostać się i wyciągać dane,
odczytywać je z twardego zapisu.
Redis będzie nam twardo zapisywał dane.
Jedyna rzecz, którą jeszcze potrzebujesz do tego to to, żeby w momencie, w którym
otworzysz sobie ten projekt, czyli zobacz Secret Weaver, to tutaj będziesz miał coś
takiego jak storage i tutaj do tego storage.
Ja tutaj miałem taką bazę, którą sobie utworzyłem jako database create database.
To będzie właśnie ta metoda, którą potrzebujesz, żeby utworzyć sobie nową
KiValue Drabble Reads i wtedy spróbować sobie to podłączyć tak,
żeby mieć twardy zapis.
Zobaczmy jak po naszym deployment wygląda teraz zapisywanie danych i czy
faktycznie nową osobę możemy dodać.
Spróbujmy sobie zrobić tutaj test i tutaj. Michał.
Mapa ok, dodajmy tutaj wszystko przebiegło pomyślnie i zobacz, że mamy
tutaj właśnie ten nasz test.
Możemy sobie też podejrzeć pod F12 i network.
Czy faktycznie to jest to, cośmy sobie zapisali, czyli tutaj w People?
Zobacz, że dostajemy ID na Noida i dostajemy e-maila, bo
to zostało przesłane.
Czyli name i email zostały przesłane.
Teraz jeżeli ja zrobiłbym deployment tej aplikacji, to wtedy okaże się,
że dostaję tylko Eve i Marka.
Dlatego, że wtedy jeszcze raz zostanie ustawiona ta serverless function.
Czyli za każdym razem gdy to peoplejs zostaje ustawiony przez Ela, no to wtedy
odświeża nam się to people, czyli jakby zerujemy stan danych.
Mamy tylko te dwie domyślne osoby.
Natomiast to już pozwala Ci się bawić dalej tak ażeby podczepić
sobie chociażby storage.
Ten storage nie musi się ograniczać tylko do KeyValue.
Jeśli chcesz wypłynąć na dużo szersze wody, zauważ, że tutaj w tych storage ach
mamy też na przykład postgresa, który może Ci zapewnić bazę SQL.