← Wszystkie tematy W 23% ogłoszeń · 11 z 47 ogłoszeń frontend React

Chmura

Wynajęty plac zabaw

Chmura pojawia się w 11 z 47 ogłoszeń frontendowych, najczęściej AWS albo Azure. Od frontendowca oczekuje się wiedzy o hostingu statycznym, CDN i cache.

Opanowane 0 z 3 pytań

Co piszą w ogłoszeniach

Scena · CDN i cache

Lodówka w każdym przedszkolu

Fabryka lizaków jest daleko, za oceanem (serwer). Żeby nie czekać, w każdym mieście stoi lodówka z zapasem (CDN), a każde dziecko ma też swoją szufladkę (cache przeglądarki). Szybko, ale jest pułapka: gdy fabryka zrobi nowy smak, szufladki i lodówki dalej mają stary. Odwiedź stronę, wdróż nową wersję i odwiedź znowu.

PlikCache-ControlSkądCzasWersja
Strona: jeszcze nie odwiedzona
na serwerze: v1

Odwiedź stronę dwa razy, potem wdróż nową wersję.

Porównajmy

Szufladka czy lodówka?

Cache przeglądarkiCDN
Gdzie stoi? U każdego dziecka.Dysk i pamięć przeglądarki użytkownika. W wielu miastach, blisko ludzi.Serwery brzegowe (edge): CloudFront, Cloudflare, Fastly, Vercel.
Kto decyduje, jak długo? Nagłówek przy pliku.Cache-Control: max-age=31536000, immutable albo no-cache. Też nagłówek, osobny dla CDN.s-maxage, reguły CDN, stale-while-revalidate.
Jak wyrzucić stare? Nie da się z zewnątrz.Dlatego nowa wersja musi mieć nową nazwę pliku (hash). Można opróżnić.Invalidation / purge po deployu, zwykle tylko index.html.
no-cache to… …nie „nie zapisuj”.Zapisz, ale przed użyciem zapytaj, czy aktualne (ETag, 304). no-store to „nie zapisuj wcale”.Do danych prywatnych, np. odpowiedzi z tokenami.
Przepis na SPA Pliki z hashem: na rok.app.3f9a.js, CSS, fonty, obrazki z hashem: immutable. index.html: zawsze sprawdzaj.no-cache + purge na CDN przy każdym wdrożeniu.

Lodówka blisko

CDN trzyma kopie blisko ludzi. Pierwszy raz wolno, potem błyskawicznie.

Nowy smak, nowa nazwa

Gdy plik się zmienia, zmienia się jego nazwa (hash). Stary może leżeć w szufladzie choćby rok.

Spis treści zawsze świeży

index.html z no-cache mówi, które pliki są aktualne. Reszta może być w szufladce.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

  1. Jak hostować statyczny frontend w chmurze? (S3 + CloudFront, CDN, cache)

    Moja odpowiedź

    Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

    Pokaż odpowiedź

    Dla przedszkolaka: Lizaki leżą w magazynie, a w każdym mieście stoi lodówka z zapasem, żeby dzieci nie czekały na dostawę zza oceanu.

    Na rozmowę: Build (dist) trafia do bucketu S3 (albo Azure Storage, GCS) z wyłączonym publicznym dostępem. Przed nim stoi CloudFront z Origin Access Control, certyfikatem z ACM i własną domeną. Dla SPA ustawiam fallback 403/404 na index.html. Nagłówki cache ustawiam przy uploadzie (aws s3 sync --cache-control), a po deployu robię invalidation dla /index.html. Infrastruktura w kodzie (Terraform, CDK), deploy z CI z rolą przez OIDC zamiast kluczy. Alternatywy z mniejszą konfiguracją to Vercel, Netlify, Cloudflare Pages.

    Umiem?
    Zapytaj Claude RozwińPrzepytaj mniePytania pogłębiające
  2. Jak skonfigurować nagłówki cache, żeby nowe wdrożenie było widoczne od razu?

    Moja odpowiedź

    Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

    Pokaż odpowiedź

    Dla przedszkolaka: Gdy fabryka robi nowy smak, dostaje on nową nazwę. Spis smaków zawsze sprawdzamy świeży, a lizaki ze starą nazwą mogą leżeć w szufladzie choćby rok.

    Na rozmowę: Pliki z hashem w nazwie (app.3f9a.js, CSS, fonty, obrazy z bundlera): Cache-Control: public, max-age=31536000, immutable, bo nowa wersja dostaje nową nazwę. index.html (i inne pliki bez hasha, np. manifest): Cache-Control: no-cache, czyli zawsze rewalidacja przez ETag (304, gdy bez zmian), plus invalidation na CDN przy deployu. no-store tylko dla danych prywatnych. Uwaga na service workera, który może trzymać starą wersję: trzeba zaplanować jego aktualizację.

    Umiem?
    Zapytaj Claude RozwińPrzepytaj mniePytania pogłębiające
  3. Co daje CDN poza szybkością?

    Moja odpowiedź

    Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

    Pokaż odpowiedź

    Dla przedszkolaka: Lodówka w mieście nie tylko jest blisko. Gdy przyjdzie tłum dzieci, magazyn się nie zatka, a strażnik przy lodówce nie wpuści łobuzów.

    Na rozmowę: Odciążenie originu (większość żądań obsługuje edge), odporność na skoki ruchu, ochrona przed DDoS i WAF, terminacja TLS i HTTP/2/3 blisko użytkownika, kompresja brotli, przekierowania i nagłówki bezpieczeństwa na brzegu, a w nowszych platformach logika na edge (Cloudflare Workers, Lambda@Edge, middleware Next.js) do A/B testów, geolokalizacji i autoryzacji.

    Umiem?
    Zapytaj Claude RozwińPrzepytaj mniePytania pogłębiające
Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

Po każdym wdrożeniu część użytkowników widzi biały ekran

SPA na S3 i CloudFront. Po każdym deployu przez kilkanaście minut Sentry zbiera setki błędów ChunkLoadError i „Failed to fetch dynamically imported module”. Użytkownicy z otwartą kartą klikają w link i dostają pusty ekran. Zespół proponuje deployować tylko w nocy.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

  • Czy rozumiesz, skąd biorą się błędy ładowania chunków po wdrożeniu
  • Czy znasz strategię atomowego wdrożenia statycznych plików
  • Czy myślisz o obu stronach: infrastrukturze i obsłudze w aplikacji

Odpowiedź seniora

Przyczyna: stara wersja aplikacji w otwartej karcie próbuje pobrać leniwy chunk z hashem, który nowy deploy usunął z bucketa. Wdrożenie usuwające stare pliki nie jest atomowe z punktu widzenia klienta.

Naprawa infrastruktury: assety z hashem w nazwie nigdy nie są kasowane przy deployu, tylko dokładane do tego samego bucketa (albo prefiksu z wersją), a sprzątanie robi lifecycle rule po np. 30 dniach. index.html ma Cache-Control: no-cache i jest podmieniany jako ostatni krok, po wgraniu wszystkich chunków. Invalidation w CloudFront dotyczy tylko index.html.

Naprawa w aplikacji: globalna obsługa błędu importu dynamicznego (handler w routerze lub wrapper na lazy), która raz przeładowuje stronę z flagą w sessionStorage, żeby nie wpaść w pętlę. Dodatkowo aplikacja może co jakiś czas sprawdzać plik version.json i proponować odświeżenie przy nawigacji. Mierzę liczbę ChunkLoadError na deploy w Sentry jako wskaźnik regresji.

Typowe wpadki

  • Deploy w nocy jako rozwiązanie
  • Kasowanie bucketa i wgrywanie od zera przy każdym wdrożeniu
  • Automatyczny reload bez zabezpieczenia przed pętlą przeładowań
  • Długi cache na index.html

Dopytają o

  • Jak zrobisz rollback, skoro stare pliki zostają w buckecie?
  • Co z service workerem, który ma własny cache?
  • Jak to wygląda przy Module Federation, gdzie remote deployuje się osobno?
Zapytaj Claude Rozwiń caseZagraj interviewera
Przypadek 2

Rachunek za transfer z CDN urósł trzykrotnie

Po kwartale finanse pytają, dlaczego koszt CloudFront i S3 wzrósł z 4 do 12 tysięcy dolarów miesięcznie, choć ruch urósł tylko o 20%. Masz znaleźć przyczynę i zaproponować plan, nie psując wydajności.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

  • Czy umiesz diagnozować koszty na podstawie danych, a nie zgadywać
  • Czy znasz mechanizmy cache i kompresji, które wpływają na transfer
  • Czy ważysz koszt przeciw wydajności i ryzyku

Odpowiedź seniora

Zaczynam od danych: raporty CloudFront (popular objects, cache statistics), logi dostępowe w Athenie i Cost Explorer z podziałem na usługi i regiony. Szukam trzech rzeczy: które obiekty generują najwięcej bajtów, jaki jest cache hit ratio i ile ruchu idzie do originu.

Typowe przyczyny: nowe nieoptymalizowane obrazy lub wideo od zespołu treści, brak kompresji Brotli dla JS, query stringi z parametrami śledzącymi wchodzące do klucza cache (każdy unikalny URL to miss), krótkie TTL na assetach z hashem, boty pobierające całe katalogi, a także ruch z regionów w droższym price class.

Plan: obrazy przez serwis optymalizacji (AVIF/WebP, rozmiary według srcset), cache policy ignorująca nieistotne parametry, Brotli, rok TTL dla hashowanych plików, Origin Shield dla mniejszego ruchu do S3, reguły WAF na złe boty, przegląd price class. Każdą zmianę mierzę osobno i ustawiam budżet z alertem w AWS Budgets, żeby kolejny skok zauważyć po tygodniu, nie po kwartale.

Typowe wpadki

  • Zmiana dostawcy CDN jako pierwszy krok
  • Obniżenie jakości wszystkich obrazów bez pomiaru
  • Brak alertu kosztowego po naprawie

Dopytają o

  • Jak sprawdzisz, czy optymalizacja obrazów nie pogorszyła LCP?
  • Kiedy opłaca się własny serwis do obrazów, a kiedy gotowy?
  • Kto w organizacji powinien być właścicielem kosztów frontendu?
Zapytaj Claude Rozwiń caseZagraj interviewera
Przypadek 3

Aplikacja dla użytkowników w Europie, USA i Azji z danymi z jednego regionu

Aplikacja SSR w Next.js stoi w jednym regionie we Frankfurcie, API też. Klienci z Australii i USA skarżą się na powolne ładowanie, TTFB z Sydney wynosi 1,8 s. Produkt chce poprawy w tym kwartale, a backend nie planuje replikacji bazy.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

  • Czy rozróżniasz, co da się przenieść na brzeg sieci, a co nie
  • Czy znasz edge rendering, cache na CDN i ich ograniczenia
  • Czy proponujesz pomiar przed i po

Odpowiedź seniora

Najpierw pomiar z regionów: RUM z podziałem na kraje (TTFB, LCP) i syntetyki z kilku lokalizacji. Rozbijam TTFB na DNS i TLS, czas do originu i czas renderowania.

Nie mogę przesunąć bazy, więc przesuwam to, co da się zcache’ować. Strony publiczne i katalog: ISR albo cache SSR na CDN z s-maxage i stale-while-revalidate, więc odpowiedź przychodzi z najbliższego POP. Strony spersonalizowane dzielę: szkielet strony z cache, a część użytkownika dociągana osobno albo streamowana. Na edge zostawiam tylko lekkie rzeczy: przekierowania, wybór języka, A/B. Renderowanie na edge z danymi z Frankfurtu nic nie da, bo każde zapytanie i tak pojedzie przez ocean, więc tego nie robię.

Do tego preconnect do API, krótsze łańcuchy żądań (mniej waterfalli) i kompresja. Jeśli po tym TTFB dla zalogowanych nadal jest za duży, przygotowuję dla backendu argumenty z danymi za read replicą w drugim regionie.

Typowe wpadki

  • Przeniesienie renderowania na edge bez przeniesienia danych
  • Cache stron spersonalizowanych bez Vary lub klucza użytkownika
  • Brak pomiaru z regionów przed decyzją

Dopytają o

  • Jak zapobiegniesz pokazaniu cudzych danych z cache CDN?
  • Co z sesją i ciasteczkami przy cache na brzegu?
  • Jak zmierzysz efekt dla biznesu, nie tylko w milisekundach?
Zapytaj Claude Rozwiń caseZagraj interviewera

Skróty klawiszowe

/
szukaj tematu
Enter
w wyszukiwarce: otwórz pierwszy wynik
N
notatki do tematu
[ ]
poprzedni / następny temat
G potem T
lista tematów
G potem P
powtórka
G potem N
wszystkie notatki
D
jasny / ciemny motyw
?
ta ściąga
Spacja, 1, 2, 3
w powtórce: pokaż, oceń

Pod każdym pytaniem są też skróty do Claude: rozwinięcie tematu, próbna rozmowa i ocena Twojej odpowiedzi z notatki.