Piszemy o tym, co dzieje się pod maską stron i aplikacji — o wydajności, o standardach, o narzędziach, których używamy na co dzień. Bez ściemy i bez marketingowego bełkotu.
Zwykły HTTP działa jak wysyłanie listów: klient pyta, serwer odpowiada. Przy czacie czy powiadomieniach to za mało — potrzebna jest linia telefoniczna, którą obie strony mogą się odezwać w dowolnym momencie. Od tego jest WebSocket.
Wyrażenia regularne wyglądają jak przypadkowy zbiór znaków, dopóki nie rozłoży się ich na części. Oto pięć wzorców z codziennej pracy, rozebranych po kawałku.
Między naciśnięciem Enter a pojawieniem się strony mija ułamek sekundy. W tym czasie dzieje się kilka rzeczy, które warto znać — choćby po to, żeby wiedzieć, gdzie szukać, kiedy strona się nie ładuje.
Klasyczny serwer daje każdemu użytkownikowi osobny wątek. Node robi wszystko w jednym i przy tysiącach połączeń bywa szybszy. Sekret nie jest skomplikowany — to kwestia tego, czym program zajmuje się przez większość czasu.
żółw zamiast żółw to klasyk, który potrafi zepsuć całą stronę. Winne jest prawie zawsze jedno: dwa miejsca w systemie dogadują się w innym kodowaniu.
Jedno API oddaje dane w stałych porcjach, drugie pozwala klientowi zamówić dokładnie to, czego potrzebuje. Oba podejścia mają sens, tylko w innych sytuacjach.
Dwa programy robiące dokładnie to samo potrafią różnić się czasem działania kilkukrotnie. Często nie chodzi o liczbę operacji, tylko o to, w jakiej kolejności program sięga po dane.
Trzy miejsca na dane użytkownika, trzy zupełnie różne zastosowania. Wybór złego to albo wyciek danych, albo koszyk, który znika po odświeżeniu strony.