Backend

HTTP

HTTP

• client-server protokol
• ze začátku: přenos hypertextových dokumentů
• nyní: přenos dat


• požadavek (klient) odpověď (server)
• textový formát, konce řádku \r\n

Požadavek (request)

• uživatel (klient) se na něco ptá serveru
• definujeme:
• method — co na daném cíli (target) chceme dělat
• target — na jakou URL se ptáme
• version — v jaké verzi HTTP požadavek odesíláme
• headers — hlavičky určující nějaké metadata
• body — nějaké informace, data, které má server zpracovat

Jaké metody existují?

Metody

• GET — na uvedený objekt, případné získání dat, nejpoužívanější, tělo je prázdné
• POST — odesílá data na server podobně jako GET, hodí se na velká data, data jsou uvnitř těla
• PUT — nahraje data na server
• PATCH — částečné modifikace objektu na serveru
• DELETE — smazání objektu na serveru
• OPTIONS — získání informací jak s objektem lze komunikovat
• HEAD, TRACE, CONNECT

Objekt (object, endpoint, zdroj) je daná URL adresa, na které se data upravují. Na serveru definujeme co je za daným objektem definováno.

• POST — odeslání dat, může mít různé následky na serveru
• PUT — přenastaví již uložený objekt
• PATCH — upraví již uložený objekt

Hlavičky jsou vždy na novém řádku, na něm je jméno a hodnota rozdělené dvojtečkou a mezerou (: ).

Co pro požadavky platí?

• bezestavové — nejsou na sebe vázané, opakované volání požadavků
• některé jsou bezpečné — pouze akce čtení (jaké?)
• uložitelné — požadavky lze uložit a volat je opakovaně
• idempotentní — volání požadavku opakovaně nemění stav serveru (jaké?)

Odpověď (Response)

• server obdrží požadavek
• požadavek zpracuje (případně odmítne)
• a odešle odpověď
• definujeme:
• statusCode — číslo označující výsledek požadavku
• statusText — lépe čitelnější odpověď (OK, Upgrade Required, Not found)
• version — v jaké verzi HTTP požadavek odesíláme
• headers — hlavičky určující nějaké metadata
• body — nějaké informace, data, které vrací uživateli

Statusové kódy

• 1xx — informační (požadavek přijat, pokračuje, ...)
• 2xx — úspěch
• 3xx — přesměrování
• 4xx — chyba požadavku (klienta) nebo nelze zpracovat
• 5xx — chyba serveru (požadavek může být v pořádku)

https://http.cat

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

Backend

• server (nebo část serveru)
• zpracovává logickou část aplikací
• připojení k databázi (dlouhodobé ukládání dat)
• letos a příští rok si ukážeme základy

Kde je nutný backend?

Co se na backendu děje?

API

• = Application Programming Interface
• Web API
• komunikační vrstva mezi backendem a frontendem
• v podstatě se s ní setkáte všude
• komunikujeme pomocí HTTP
• webová služba
• balíček URL zdrojů a operací

Znáte nějaké API?

Pokuste se API k nějaké službě najít.

REST

• architektonický vzor k vytváření moderního API
• když API dodržuje REST, říkáme, že je RESTful
• požadavky:
• volání akcí, nýbrž práce se zdroji
• každý zdroj je jednoznačně určen URL
• práci určují HTTP metody
• jeden zdroj může mít více reprezentací
• zdroje jsou navzájem propojené a API je linkuje

REST API URI

https://api-ssps.cajthaml.eu
/subject/61253075a238ce375c4ade63
/grading
/user/612539031a6bab58d056b34b

CRUD

• = CREATE READ UPDATE DELETE
• určuje, jaké akce by na zdrojích měly být k dispozici

Nyní víme, jak se komunikuje v HTTP.

Jakými formáty lze předávat data (tělo/body) v API?

Datové formáty

• čistý text
• XML
• JSON
• a další

XML

• rodič HTML
• byl vytvořen na předávání dat
• nejsou definované žádné elementy

Jak se liší HTML a XML?

Ukázka XML

Může API předávat data ve formátu HTML?

JSON

• = JavaScript Object Notation
• stručný formát na předávání dat
• čte se dobře strojově ale i lidmi
• velmi se podobá obyčejnému JS (objekty a pole)

JSON datové typy

• řetězec
• číslo
• objekt
• pole
• null

Ukázka JSON

Jak se liší JSON a JS zápis objektů?

Je tento zápis JSON platný?

Jaké výhody a nevýhody má plaintext, XML a JSON?

Platí tyto formáty pouze pro komunikaci Server → Klient?

Verzování API

• číslování
• oznámení
• doby běhu

Kdy je potřeba změnit verzi API?

Správa obsahu

Práce

Zkusme navrhnout API (endpointy), které slouží ke správě obsahu na webových stránkách. Tedy: příspěvky, uživatele, komentáře a další.

E-shop

Práce

Zkusme navrhnout API (endpointy), které slouží ke správě obchodu (bez administrace), tedy: předměty, přihlášení, košík, objednávka a další.

AJAX

• = Asynchronous JavaScript And XML
• dovoluje nám vytvářet dynamické stránky
• prakticky získáváme údaje pro stránku v kódu
• není nutné refreshovat stránku
• odesílání dat na server

Odesílání požadavků

• požadavky odesíláme pomocí XMLHttpRequest
• jsou to předpřipravené třídy určené k odesílání požadavků
• jako v HTTP definujeme metodu, cíl, hlavičky a další

Ukázka XMLHttpRequest

Líbí se Vám tento postup?

Odesílání pomocí FetchAPI

• modernější než XMLHttpRequest
• CanIUse Fetch
• zcela využívá Promises

Ukázka Fetch

Jak Fetch dokázal přečíst string JSONu do objektů?

• v JS máme k dispozici třídu JSON
• dovoluje převádět JSON ⟷ string
• JSON.stringify(obj)
• JSON.parse(str)

Ukázka JSON

CORS

• = Cross-origin resource sharing
• mechanismus zabezpečení webové stránky
• každý server si může říct, jaké domény mají k datům přístup
• prohlížeč potom tyto nastavení kontroluje

CORS hlavičky

• Access-Control-Allow-Origin: https://cajthaml.eu
• Access-Control-Allow-Origin: *
• odesílá server např. při požadavku OPTIONS

Express

Express

• nejpopulárnější framework pro Node.js
• jednoduchý, ale řeší nemalé problémy
• routování, middleware, šablony, ...
• mnoho pluginů

Instalace & použití

• do projektu stačí nainstalovat express
• poté stačí vytvořit instanci aplikace
• aplikaci poté řekneme, ať naslouchá na portu
• daný port poté používáme v aplikacích

Ukázka použití

Endpointy

• routování pomocí metody app.METHOD
• zadáváme cestu a funkci (middleware), která se má zavolat
• máme k dispozici požadavek a odpověď

Ukázka endpointu

Middleware

Middleware

• funkce s parametry
• přijme požadavek, možná provede nějakou akci a možná předá ho další middleware v pořadí
• může mít různé účely — v definici nemusí být funkce, ale program, fyzikální zařízení, ...
• parametry:
• req — požadavek
• res — odpověď
• next — funkce pro zavolání další middleware

Middleware

• používáme na endpoint
• můžeme použít globálně pro celou aplikaci či část
• můžeme jich použít více po endpointu

Aplikace s odpovědí

Omezení přístupu

Omezení přístupu na endpoint

CORS

Middleware s parametry

Vstup

Vstup

• čteme z těla požadavku
• někdy i URL (query parametry, cesta)
• někdy i hlavičky
• potřebujeme něco, co nám zpracuje tyto data

body-parser

• plugin pro Express
• zpracovává tělo požadavku
• nastavíme si, jaký formát očekáváme, ale např. i velikost
• přidáme ho jako middleware

Ukázka použití

Fujky data

• co když datům nevěříme (tj. vždy)?
• potřebujeme validaci
• ruční podmínky a další je nebezpečné a nepříjemné
• můžeme použít knihovnu
• např. express-validator, joi, ...

Ukázka použití

Opakování DB

Opakování DB

• databáze
• typy databází — relační, dokumentové, ...
• SQL
• tabulka, řádek, sloupec, primární klíč, cizí klíč
• dotazy
• ORM

Vytvoření tabulky

Vytvoření řádku

Výběry 1

Výběry 2

Výběry 3

Výběry 4

Výběry 5

Úprava řádku

Smazání řádku

Pořadí

Více pořadí

Limitování a posun

Unikátní hodnoty

Počet

Suma, min, max, průměr

Pojmenování

Seskupení

Seskupení s agregací

Filtrování po agregaci

Inner join

Join s podmínkou

Použití DB na backendu

DB v Node.js

• spousta knihoven
• ukážeme si pg pro PostgreSQL
• ORM: sequelize, prisma, ...

Připojení

Výběr

Ukázky v pg

SQL Injection

• bezpečnostní chyba
• do parametru můžeme vložit vlastní SQL kód
• co bychom mohli provést pomocí SQL Injection v minulém příkladu?

Řešení SQL Injection

• nepoužívat čisté vkládání do SQL dotazu
• použít správné metody nebo escapovat vstup
• často taktéž tzv. prepared statements

Řešení SQL Injection

Správa serveru

Reverzní proxy

• proxy, která přesměrovává požadavky na jiný server či port
• často se používá pro zajištění bezpečnosti, load balancingu, škálování, ...

Reverzní proxy

sequenceDiagram
    actor Client
    participant Proxy
    
    box Server
        participant App A as Server/App A
        participant App B as Server/App B
    end
    
    Client ->> Proxy: Request A (port 80)
    Proxy ->> App A: Request (port 3000)
    activate App A
    App A ->> Proxy: Response
    deactivate App A
    Proxy ->> Client: Response
    
    Client ->> Proxy: Request B (port 80)
    Proxy ->> App B: Request (port 3001)
    activate App B
    App B ->> Proxy: Response
    deactivate App B
    Proxy ->> Client: Response