Konrad Kowalski (rootsher)Principal Platform & Reliability Architect001100101101111010010011111001110110000010100101

Backend

wpisy (20)

  1. Warstwy HTTP w przeglądarce: od fetch() do QUIC4/9

    Browser nie daje JavaScriptowi pełnej kontroli nad HTTP

    fetch() nie jest gołym socketem. Cookies, cache, preflight i część nagłówków należą do przeglądarki, więc jedna operacja w kodzie nie równa się jednemu…

  2. Warstwy HTTP w przeglądarce: od fetch() do QUIC3/9

    Headers i Body: metadane kontra reprezentacja

    Body to bajty, a nie JSON. Headers mówią, jak je czytać, i sterują cache, cookies oraz CORS, choć aplikacja nie ma nad nimi pełnej kontroli.

  3. Warstwy HTTP w przeglądarce: od fetch() do QUIC2/9

    Methods i status codes: semantyka, nie dekoracja

    Metoda i status mówią browserowi oraz infrastrukturze, co wolno zrobić z requestem. Dlatego retry POST-a jest inną decyzją niż retry GET-a.

  4. Warstwy HTTP w przeglądarce: od fetch() do QUIC1/9

    Request i Response: co faktycznie wysyła browser?

    Request to nie URL, a odpowiedź HTTP to nie zawsze JSON. Headers i body mają osobny lifecycle, a błąd HTTP nie jest awarią sieci.

  5. seria · 9 części

    Warstwy HTTP w przeglądarce: od fetch() do QUIC

    Dwie linie z fetch() zakrywają kilka warstw: browser API, semantykę HTTP, wire protocol i transport. Seria rozdziela je tak, żeby Network panel dał się czytać.

  6. Realtime w przeglądarce: od pollingu do WebTransport7/7

    Polling, Streaming, SSE, WebSocket czy WebTransport?

    Wybór wynika z modelu ruchu: świeżości danych, kierunku, częstotliwości, kolejności i niezawodności. Najprostszy poprawny mechanizm zwykle wygrywa.

  7. Realtime w przeglądarce: od pollingu do WebTransport6/7

    WebTransport: streams i datagramy dla realtime nad HTTP/3

    HTTP/3 i QUIC dają jednej sesji wiele niezależnych streamów oraz datagramy. Nie każde dane muszą dotrzeć niezawodnie i w kolejności.

  8. Realtime w przeglądarce: od pollingu do WebTransport5/7

    WebSockets: trwały kanał komunikacji w obu kierunkach

    Po handshake nie ma już requestów i odpowiedzi, tylko frames. Trwałe połączenie jest stanem, który dotyka load balancera, deployu i fan-outu między instancjami.

  9. Realtime w przeglądarce: od pollingu do WebTransport4/7

    Server-Sent Events: protokół zdarzeń nad HTTP streamingiem

    Standardowy format zdarzeń i reconnect nad strumieniem HTTP. Last-Event-ID daje wznowienie, ale trwałości eventów w systemie już nie załatwia.

  10. Realtime w przeglądarce: od pollingu do WebTransport3/7

    HTTP Streaming: jedna odpowiedź, wiele fragmentów danych

    Odpowiedź może powstawać w czasie. Chunk transportowy nie jest wiadomością, więc framing i backpressure stają się sprawą aplikacji.