Crearea unei aplicații utilizând cadru fără server, AWS și BigQuery
Publicat: 2021-01-28Serverless se referă la aplicațiile în care gestionarea și alocarea serverelor și resurselor sunt gestionate de un furnizor de cloud. Aceasta înseamnă că furnizorul de cloud alocă dinamic resursele. Aplicația rulează într-un container fără stat care poate fi declanșat de un eveniment. Un astfel de exemplu de mai sus și cel pe care îl vom folosi în acest articol este despre AWS Lambda .
Pe scurt, putem determina „aplicații fără server” ca aplicații care sunt sisteme bazate pe cloud bazate pe evenimente. Aplicația se bazează pe servicii terțe, pe logica clientului și pe apeluri de la distanță (apelând direct Function as a Service ).
Instalarea unui cadru fără server și configurarea lui pentru Amazon AWS

1. Cadru fără server
Framework-ul Serverless este un cadru open-source. Acesta constă dintr-o interfață de linie de comandă sau CLI și un tablou de bord găzduit, care ne oferă un sistem de gestionare a aplicațiilor complet fără server. Utilizarea cadrului asigură mai puține cheltuieli generale și costuri, dezvoltarea și implementarea rapidă și securizarea aplicațiilor fără server.
Înainte de a continua instalarea cadrului Serverless, mai întâi trebuie să configurați NodeJS. Este foarte ușor de făcut pe majoritatea sistemelor de operare – trebuie doar să vizitați site-ul oficial NodeJS pentru a-l descărca și instala. Nu uitați să alegeți o versiune mai mare decât 6.0.0.
După instalarea acestuia, puteți confirma că NodeJS este disponibil rulând node -v în consolă. Ar trebui să returneze versiunea nodului pe care ați instalat-o:

Acum sunteți gata, așa că mergeți mai departe și instalați framework-ul Serverless.
Pentru a face acest lucru, urmați documentația pentru a configura și configura cadrul. Dacă preferați, îl puteți instala doar pentru un singur proiect, dar la DevriX, de obicei instalăm cadrul global: npm install -g serverless
Așteptați ca procesul să se termine și asigurați-vă că Serverless s-a instalat cu succes rulând: serverless -v

2. Creați un cont Amazon AWS
Înainte de a continua să creați aplicația eșantion, ar trebui să creați un cont în Amazon AWS . Dacă nu aveți încă unul, este la fel de simplu ca să accesați Amazon AWS și să faceți clic pe „Creați un cont AWS” în colțul din dreapta sus și să urmați pașii pentru a crea un cont.

Amazon vă solicită să introduceți un card de credit, așa că nu puteți continua fără a introduce informațiile respective. La înregistrarea și autentificarea cu succes, ar trebui să vedeți Consola de management AWS:

Grozav! Să continuăm acum cu crearea aplicației dvs.
3. Configurați cadrul fără server cu furnizorul AWS și creați un exemplu de aplicație
În acest pas, trebuie să configuram cadrul Serverless cu furnizorul AWS. Unele servicii, cum ar fi AWS Lambda, necesită acreditări atunci când le accesați, pentru a vă asigura că aveți permisiuni pentru resursele deținute de serviciul respectiv. AWS recomandă utilizarea AWS Identity and Access Manager (IAM) pentru a realiza acest lucru.
Deci, primul și cel mai important lucru este să creați un utilizator IAM în AWS pentru a-l folosi în aplicația noastră:
La consola AWS:
- Tastați IAM în câmpul „Găsiți servicii” .
- Faceți clic pe „IAM” .
- Accesați „Utilizatori” .
- Faceți clic pe „Adăugați utilizator” .

Pentru „Nume utilizator” folosiți orice doriți. De exemplu, folosim serverless-admin. Pentru „ Tip de acces” bifați „Acces programat” și faceți clic pe „Permisiunile următoare ”.

După aceea, trebuie să atașăm permisiuni pentru utilizator, să facem clic pe „Atașați direct politicile existente”, să căutați „Acces administrator” și să faceți clic pe el. Continuați cu clic pe „Etichetele următoare”

Etichetele sunt opționale, așa că puteți continua făcând clic pe „Următoarea revizuire” și „Creați utilizator”. Odată terminat și încărcat, pe pagina apare un mesaj de succes cu acreditările de care avem nevoie.

Acum trebuie să rulăm următoarea comandă:
serverless config credentials --provider aws --key key --secret secret --profile serverless-admin
Înlocuiți cheia și secretul cu cel furnizat mai sus. Acreditările dvs. AWS sunt create ca profil. Puteți verifica asta de două ori deschizând fișierul ~/.aws/credentials . Ar trebui să conțină profiluri AWS. În prezent, în exemplul de mai jos, este doar unul – cel pe care l-am creat:

O treabă grozavă până acum! Puteți continua prin crearea unui exemplu de aplicație folosind NodeJS și șabloanele de pornire încorporate.
Notă: În plus, în articol, folosim comanda sls , care este prescurtarea de la serverless .
Creați un director gol și introduceți-l. Rulați comanda
ls create --template aws-nodejs
Folosind comanda create –template , specificați unul dintre șabloanele disponibile, în acest caz, aws-nodejs, care este o aplicație de șablon NodeJS „Hello world”.

Odată terminat, directorul dvs. ar trebui să fie format din următoarele și să arate astfel:

Am creat noile fișiere handler.js și serverless.yml .
Fișierul handler.js stochează funcțiile dvs., iar serverless.yml stochează proprietățile de configurare pe care le veți modifica mai târziu. Dacă vă întrebați ce este fișierul .yml , pe scurt, este un limbaj de serializare a datelor care poate fi citit de om . Este bine să fii familiarizat cu el, deoarece este folosit la introducerea oricăror parametri de configurare. Dar să aruncăm o privire la ceea ce avem acum în fișierul serverless.yml :
serviciu: aws-sample-application
furnizor:
nume: aws
timp de rulare: nodejs12.x
functii:
Buna ziua:
handler: handler.hello
- serviciu: – Numele serviciului nostru.
- provider: – Un obiect care conține proprietățile furnizorului și, după cum vedem aici, furnizorul nostru este AWS și folosim runtime NodeJS.
- funcții: – Este un obiect care conține toate funcțiile care pot fi implementate în Lambda. În acest exemplu, avem o singură funcție numită hello care indică funcția handler.js hello.
Trebuie să faceți un lucru crucial aici înainte de a continua cu implementarea aplicației. Mai devreme, am setat acreditările pentru AWS cu un profil (l-am numit serverless-admin ). Acum tot ce trebuie să faci este să spui configurației fără server să folosească acel profil și regiunea ta. Deschide serverless.yml și sub proprietatea furnizorului , chiar sub runtime, introduceți aceasta:
profil: serverless-admin regiune: noi-est-2
La final, ar trebui să avem așa:
furnizor: nume: aws timp de rulare: nodejs12.x profil: serverless-admin regiune: noi-est-2
Notă: Pentru a obține regiunea, o modalitate ușoară este să căutați adresa URL atunci când v-ați conectat la consolă: Exemplu:

Acum că avem informațiile necesare despre șablonul nostru generat. Să verificăm cum putem invoca funcția local și să o implementăm în AWS Lambda.
Putem testa imediat aplicația invocând funcția local:
sls invoke local -f hello
Invocă funcția (dar numai local!) și returnează rezultatul în consolă:

Acum, dacă totul a mers OK, puteți încerca să vă implementați funcția pe AWS Lambda .
Deci, a fost complicat? Nu, nu a fost! Datorită cadrului Serverless , este doar un cod cu o singură linie:
sls deploy -v
Așteptați ca totul să se termine, poate dura câteva minute, dacă totul este în regulă, ar trebui să închei cu ceva de genul:

Acum să verificăm ce s-a întâmplat în AWS. Accesați Lambda (în „ Găsiți servicii ”, tastați Lambda ) și ar trebui să vedeți funcția dvs. Lambda creată.

Acum puteți încerca să vă invocați funcția din AWS Lambda. În tipul terminalului
sls invoke -f hello
Ar trebui să returneze aceeași ieșire ca mai devreme (când testăm local):

Puteți verifica dacă ați declanșat funcția AWS deschizând funcția în AWS Lambda și accesând fila „ Monitorizare ” și făcând clic pe „ Vizualizați jurnalele în CloudWatch. „.

Ar trebui să aveți un singur jurnal acolo.
Acum, încă lipsește un lucru din aplicația dvs., dar ce este...? Ei bine, nu aveți un punct final la care să accesați aplicația dvs., așa că haideți să-l creăm folosind AWS API Gateway.
Mai întâi trebuie să deschideți fișierul serverless.yml și să curățați comentariile. Trebuie să adăugați o proprietate de evenimente la funcția noastră și sub proprietatea sa http . Aceasta îi spune cadrului Serverless să creeze un Gateway API și să îl atașeze la funcția noastră Lambda atunci când implementează aplicația. Fișierul nostru de configurare ar trebui să se termine în asta:
serviciu: aws-sample-application
furnizor:
nume: aws
timp de rulare: nodejs12.x
profil: serverless-admin
regiune: noi-est-2
functii:
Buna ziua:
handler: handler.hello
evenimente:
- http:
cale: /bună ziua
metoda: obtine
În http specificăm calea și metoda HTTP.
Gata, haideți să implementăm din nou aplicația noastră rulând sls deploy -v
Odată ce este terminat, ar trebui să apară un lucru nou în terminalul de ieșire și acesta este punctul final care a fost creat:

Să deschidem punctul final:

Ar trebui să vedeți că funcția dvs. se execută, returnează rezultate și câteva informații despre cerere. Să verificăm ce se schimbă în funcția noastră Lambda.
Deschideți AWS Lambda și faceți clic pe funcția dvs.

Vedem în fila „ Designer ” că avem API Gateway atașat la Lambda și la punctul final API.
Grozav! Ați creat o aplicație super simplă fără server, ați implementat-o în AWS Lambda și i-ați testat funcționalitatea. De asemenea, am adăugat un punct final folosind AWS API Gateway .
4. Cum să rulați aplicația offline
Până acum, știm că putem invoca funcții local, dar, de asemenea, ne putem rula întreaga aplicație offline folosind plugin-ul serverless-offline.
Pluginul emulează AWS Lambda și API Gateway pe mașina dvs. locală/de dezvoltare. Pornește un server HTTP care se ocupă de cereri și vă invocă handlerii.
Pentru a instala pluginul, rulați comanda de mai jos în directorul aplicației
npm install serverless-offline --save-dev
Apoi, în interiorul serverless.yml al proiectului, deschideți fișierul și adăugați proprietatea pluginurilor :
pluginuri: - serverless-offline
Configurația ar trebui să arate așa:
serviciu: aws-sample-application
furnizor:
nume: aws
timp de rulare: nodejs12.x
profil: serverless-admin
regiune: noi-est-2
functii:
Buna ziua:
handler: handler.hello
evenimente:
- http:
cale: /bună ziua
metoda: obtine
pluginuri:
- serverless-offline
Pentru a verifica dacă am instalat și configurat cu succes pluginul rulați
sls --verbose
Ar trebui să vezi asta:

Acum, în rădăcina proiectului, rulați comanda
sls offline

După cum puteți vedea, un server HTTP ascultă pe portul 3000 și vă puteți accesa funcțiile, de exemplu, aici avem http://localhost:3000/dev/hello pentru funcția noastră hello. Deschidem că avem același răspuns ca de la API Gateway , pe care l-am creat mai devreme.

Adăugați integrarea Google BigQuery

Ai făcut o treabă grozavă până acum! Aveți o aplicație complet funcțională folosind Serverless. Să extindem aplicația noastră și să îi adăugăm integrarea BigQuery pentru a vedea cum funcționează și cum se realizează integrarea.
BigQuery este un software ca serviciu (SaaS) fără server, adică un depozit de date rapid și rentabil, care acceptă interogări. Înainte de a continua să îl integrăm cu aplicația noastră NodeJS, trebuie să ne creăm un cont, așa că haideți să continuăm.

1. Configurați Google Cloud Console
Accesați https://cloud.google.com și conectați-vă cu contul dvs., dacă nu ați făcut deja - creați un cont și continuați.
Când vă conectați la Google Cloud Console, trebuie să creați un nou proiect. Faceți clic pe cele trei puncte de lângă logo și se va deschide o fereastră modală în care alegeți „ Proiect nou. ”

Introduceți un nume pentru proiectul dvs. Vom folosi bigquery-example . După ce ați creat proiectul, navigați la BigQuery folosind sertarul:

Când BigQuery se încarcă, în partea stângă, veți vedea datele proiectului, la care aveți acces, precum și seturile de date publice. Utilizăm un set de date publice pentru acest exemplu. Se numește covid19_ecdc :

Joacă în jurul setului de date și a meselor disponibile. Previzualizează datele din el. Acesta este un set de date public care este actualizat din oră în oră și conține informații despre datele despre COVID-19 la nivel mondial.
Trebuie să creăm un utilizator IAM -> Cont de service pentru a putea accesa datele. Deci, în meniu, faceți clic pe „IAM & Admin”, apoi pe „Conturi de servicii”.

Faceți clic pe butonul „Creați cont de serviciu” , introduceți numele contului de serviciu și faceți clic pe „Creați”. Apoi, accesați „ Permisiunile contului de serviciu” , căutați și alegeți „Admin BigQuery” .

Faceți clic pe „ Continuați ”, acesta este ultimul pas, aici aveți nevoie de cheile dvs., așa că faceți clic pe butonul de creare de sub „ Chei ” și exportați ca JSON . Salvați asta undeva în siguranță, vom avea nevoie de el mai târziu. Faceți clic pe Terminat pentru a finaliza crearea contului de serviciu.

Acum, vom folosi acreditările generate aici pentru a conecta biblioteca NodeJS BigQuery.
2. Instalați Biblioteca NodeJS BigQuery
Va trebui să instalați biblioteca BigQuery NodeJS pentru a o utiliza în proiectul pe care tocmai l-ați creat. Rulați comenzile de mai jos în directorul aplicației:
Mai întâi, inițializați npm rulând npm init
Completați toate întrebările și continuați cu instalarea bibliotecii BigQuery :
npm install @google-cloud/bigquery
Înainte de a continua să ne schimbăm handlerul de funcții, trebuie să purtăm cheia privată din fișierul JSON pe care l-am creat anterior. Vom folosi variabile de mediu Serverless pentru a face acest lucru. Puteți obține mai multe informații aici.
Deschide serverless.yml și, în proprietatea furnizorului , adaugă proprietatea de mediu astfel:
mediu inconjurator:
PROJECT_ID: ${file(./config/bigquery-config.json):project_id}
CLIENT_EMAIL: ${file(./config/bigquery-config.json):client_email}
PRIVATE_KEY: ${file(./config/bigquery-config.json):private_key}
Creați variabile de mediu PROJECT_ID, PRIVATE_KEY și CLIENT_EMAIL , care iau aceleași proprietăți (minuscule) din fișierul JSON pe care l-am generat. L-am plasat în folderul de configurare și l-am numit bigquery-config.json .
În acest moment, ar trebui să ajungeți cu fișierul serverless.yml care arată astfel:
serviciu: aws-sample-application
furnizor:
nume: aws
timp de rulare: nodejs12.x
profil: serverless-admin
regiune: noi-est-2
mediu inconjurator:
PROJECT_ID: ${file(./config/bigquery-config.json):project_id}
CLIENT_EMAIL: ${file(./config/bigquery-config.json):client_email}
PRIVATE_KEY: ${file(./config/bigquery-config.json):private_key}
functii:
Buna ziua:
handler: handler.hello
evenimente:
- http:
cale: /bună ziua
metoda: obtine
pluginuri:
- serverless-offline
Acum deschide handler.js și permite să importăm biblioteca BigQuery, în partea de sus a fișierului, sub „utilizați strict”, adăugați următoarea linie:
const {BigQuery} = require('@google-cloud/bigquery');
Acum trebuie să spunem bibliotecii BigQuery acreditările. În acest scop, creați o nouă constantă care instanțiază BigQuery cu acreditările:
const bigQueryClient = nou BigQuery({
projectId: process.env.PROJECT_ID,
acreditări: {
client_email: process.env.CLIENT_EMAIL,
cheie_privată: process.env.PRIVATE_KEY
}
});
Apoi, să creăm interogarea noastră SQL BigQuery. Dorim să recuperăm cele mai recente informații despre cazurile de COVID-19 pentru Bulgaria. Utilizăm editorul de interogări BigQuery pentru a-l testa înainte de a continua, așa că am creat o interogare personalizată:
SELECTAȚI * DIN `bigquery-public-data.covid19_ecdc.covid_19_geographic_distribution_worldwide` WHERE geo_ ORDER BY data DESC LIMIT 1

Bun! Acum să implementăm asta în aplicația noastră NodeJS.
Deschide handler.js și inserează codul de mai jos
const query = 'SELECT * FROM `bigquery-public-data.covid19_ecdc.covid_19_geographic_distribution_worldwide` WHERE geo_id = \'BG\' ORDER BY data DESC LIMIT 1';
opțiuni const = {
interogare: interogare
}
const [job] = așteaptă bigQueryClient.createQueryJob(opțiuni);
const [rows] = await job.getQueryResults();
Am creat constante de interogare și opțiuni . Apoi continuăm cu rularea interogării ca job și preluarea rezultatelor din aceasta.
Să modificăm, de asemenea, handlerul de returnare pentru a returna rândurile generate din interogare:
întoarcere {
statusCod: 200,
body: JSON.stringify(
{
rânduri
},
nul,
2
),
};
Să vedem întregul handler.js :
„utilizați strict”;
const {BigQuery} = require('@google-cloud/bigquery');
const bigQueryClient = nou BigQuery({
projectId: process.env.PROJECT_ID,
acreditări: {
client_email: process.env.CLIENT_EMAIL,
cheie_privată: process.env.PRIVATE_KEY
}
});
module.exports.hello = eveniment asincron => {
const query = 'SELECT * FROM `bigquery-public-data.covid19_ecdc.covid_19_geographic_distribution_worldwide` WHERE geo_id = \'BG\' ORDER BY data DESC LIMIT 1';
opțiuni const = {
interogare: interogare
}
const [job] = așteaptă bigQueryClient.createQueryJob(opțiuni);
const [rows] = await job.getQueryResults();
întoarcere {
statusCod: 200,
body: JSON.stringify(
{
rânduri
},
nul,
2
),
};
};
Bine! Să ne testăm funcția local:
sls invoke local -f hello
Ar trebui să vedem rezultatul:

Continuați cu implementarea aplicației pentru a o testa prin punctele finale HTTP, așa că rulați sls deploy -v
Așteptați să se termine și deschideți punctul final. Iată rezultatele:

Bine făcut! Acum avem o aplicație pentru a prelua date din BigQuery și a returna un răspuns! Să verificăm în sfârșit dacă funcționează offline. Rulați sls offline
Și încărcați punctul final local:

Lucru bine făcut. Suntem aproape la finalul procesului. Ultimul pas este să schimbați ușor aplicația și comportamentul. În loc de AWS API Gateway , dorim să folosim aplicația Load Balancer . Să vedem cum să reușim asta în capitolul următor.
ALB – Aplicație Load Balancer în AWS
Am creat aplicația noastră folosind AWS API Gateway. În acest capitol, vom trata cum să înlocuim API Gateway cu Application Load Balancer (ALB).
Mai întâi, să vedem cum funcționează echilibrul de încărcare a aplicației în comparație cu API Gateway:
În aplicația de echilibrare a încărcăturii, mapăm o anumită cale (de exemplu, /hello/ ) către un grup țintă - un grup de resurse, în cazul nostru, funcția Lambda .
Un grup țintă poate avea asociată o singură funcție Lambda. Ori de câte ori grupul țintă trebuie să răspundă, echilibratorul de încărcare a aplicației trimite o solicitare către Lambda, iar funcția trebuie să răspundă cu un obiect de răspuns. La fel ca API Gateway, ALB se ocupă de toate solicitările HTTP(e).
Există unele diferențe între ALB și API Gateway . O diferență principală este că API Gateway acceptă numai HTTPS (SSL), în timp ce ALB acceptă atât HTTP, cât și HTTPS.
Dar, să vedem câteva avantaje și dezavantaje ale Gateway-ului API:
Gateway API:
Pro:
- Securitate excelentă.
- Este simplu de implementat.
- Este rapid pentru desfășurare și gata într-un minut.
- Scalabilitate și disponibilitate.
Contra:
- Poate deveni destul de scump când se confruntă cu trafic ridicat.
- Este nevoie de mai multă orchestrare, ceea ce adaugă un nivel de dificultate pentru dezvoltatori.
- Degradarea performanței, din cauza scenariilor API, poate afecta viteza și fiabilitatea aplicației.
Să continuăm cu crearea unui ALB și să trecem la el în loc să folosim API Gateway:
1. Ce este ALB?
Echilibratorul de încărcare a aplicației permite dezvoltatorului să configureze și să direcționeze traficul de intrare. Este o caracteristică a „ Echilibrare elastică a sarcinii”. Acesta servește ca punct unic de contact pentru clienți, distribuie traficul de aplicații de intrare în mai multe ținte, cum ar fi instanțe EC2 în mai multe zone.
2. Creați un aplicație Load Balancer utilizând interfața de utilizare AWS
Să creăm aplicația Load Balancer (ALB) prin interfața de utilizare în Amazon AWS. Conectați-vă la Consola AWS în „ Găsiți servicii. ” tastați „ EC2 ” și găsiți „ Load Balancers. ”

Faceți clic pe „ Creare Load Balancer ”, sub „ Application Load Balancer ”, alegeți „ Creare ”. Pentru un nume, introduceți alegerea dvs., am folosit „ sample-alb”, alegeți Scheme „ internet-facing ”, tip de adresă IP ipv4.
Pe „ Ascultători ”, lăsați-l așa cum este – HTTP și portul 80. Poate fi configurat pentru HTTPS, deși trebuie să aveți un domeniu și să îl confirmați înainte de a putea utiliza HTTPS.
Zone de disponibilitate – Pentru VPC alege-o pe cea pe care o ai din meniul derulant și marchează toate „ Zone de disponibilitate” :

Faceți clic pe „ Următorul Configurați setările de securitate ” pentru a vă solicita să îmbunătățiți securitatea echilibratorului de încărcare. Faceți clic pe Următorul.
La „ Pasul 3. Configurați grupuri de securitate ”, la Atribuiți un grup de securitate pentru a alege „Creați un nou grup de securitate”. Continuați în continuare făcând clic pe „ Următorul: Configurați rutarea. „. La pasul 4, configurați-l așa cum se arată în captura de ecran de mai sus:

Faceți clic pe Următorul , Următorul și Creare .
Reveniți la echilibrarea încărcăturii și copiați ARN-ul așa cum se arată în captura de ecran:

Acum trebuie să ne schimbăm serverless.yml și să eliminăm proprietatea http API Gateway. Sub proprietatea evenimente, eliminați proprietatea http și adăugați o proprietate alb. Obiectul funcție ar trebui să se termine astfel:
Buna ziua:
handler: handler.hello
evenimente:
- alba:
listenerArn: arn:aws:elasticloadbalancing:us-east-2:115129174008:listener/app/sample-alb/ae6e398a898c48e6/67ce6bf319d0513d
prioritate: 1
conditii:
cale: /bună ziua
Salvați fișierul și rulați comanda pentru implementarea aplicației
sls deploy -v
După implementarea cu succes, reveniți la AWS Load Balancers și găsiți numele dvs. DNS așa cum se arată în captura de ecran:

Copiați numele DNS și introduceți calea /hello .
Ar trebui să funcționeze și, eventual, să vă ofere opțiunea de a descărca conținut :). Până acum, echilibrarea încărcării aplicației funcționează minunat, dar aplicația trebuie să returneze un răspuns adecvat pentru utilizatorii noștri finali. Pentru a face acest lucru, deschideți handler.js și înlocuiți instrucțiunea return cu cea de mai jos:
întoarcere {
statusCod: 200,
statusDescription: "200 OK",
anteturi: {
„Content-Type”: „application/json”
},
isBase64Encoded: fals,
body: JSON.stringify(rânduri)
}
Diferența ALB este că răspunsul trebuie să includă statusDescription, anteturi și isBase64Encoded. Vă rugăm să salvați fișierul și să implementați din nou, dar de data aceasta nu întreaga aplicație, ci doar funcția pe care am schimbat-o. Rulați comanda de mai jos:
sls deploy -f hello
În acest fel, definim doar funcția hello de implementat. După implementarea cu succes, vizitați din nou numele DNS cu calea și ar trebui să aveți un răspuns adecvat!

Grozav! Acum am înlocuit API Gateway cu Application Load Balancer. Aplicația Load balancer este mai ieftină decât API Gateway și acum ne putem extinde aplicația pentru a ne satisface nevoile, mai ales dacă ne așteptăm să avem un trafic mai mare.
Cuvinte finale
Am creat o aplicație simplă folosind Serverless Framework, AWS și BigQuery și am acoperit utilizarea sa principală. Serverless este viitorul și este ușor să gestionați o aplicație cu el. Continuați să învățați și aruncați-vă în cadrul Serverless pentru a explora toate funcționalitățile sale și secretele pe care le are. Este, de asemenea, un instrument destul de simplu și convenabil.
