Mam dla was 3 terminy wyciągnięte z najdalszych czeluści świata web developmentu. Podejrzewam, że jest to pierwszy wpis całej serii. Znając życie na pewno wpadnę jeszcze na niejedno dziwne pojęcie, którym będę chciała się z Wami podzielić!
Blobularization
To pojęcie związane jest z protokołem HTTP. Stara szkoła HTTP1.x radzi, aby wszystkie pliki strony łączyć ze sobą w jak największym stopniu. Tak, aby wysłać klientowi 1 ogromny plik .js, 1 gigantyczny plik .css oraz 1 olbrzymi sprite obrazków. Słowem – na produkcję wrzucaj jak najmniej jak największych plików. Ową technikę sprytnie można nazwać blobularyzacją. Tak, wiem – takiego słowa nie ma w języku polskim, właśnie je wymyśliłam. Cóż, wydaje mi się, że owy neologizm dosyć dobrze reprezentuje oryginał, więc zamierzam go szeroko propagować. Dziś, w dobie HTTP2, wiemy, że blobularyzacja okazuje się być antywzorcem. Ilość wysyłanych plików przestaje mieć znaczenie, od kiedy HTTP2 wprowadza multiplexing (tu multipleksowanie po polsku brzmi o wiele gorzej). Z kolei mniejsze pliki są bardziej przyjazne podczas renderowania wszelakich zmian na stronie (np. podczas zmiany czcionki podmieniany jest tylko jeden mały plik, reszta siedzi w cache przeglądarki). Nie będę się jednak rozpisywać nad dobrymi praktykami HTTP2. To temat na osobny wpis, ale przede wszystkim to kwestia sporna, oczywiście zależna od wymagań projektu.
Źródło blobularyzacji: KLIK!
Hearbeating
Tego pojęcia też nie googlajcie. Bez sensu! Nie mam zamiaru go tłumaczyć na język polski, bo heartbeating brzmi dosyć sympatycznie. Ale przejdźmy do konkretów. Heartbeating związany jest z web socketami. Generalnie web socket to technologia tworząca magiczne połączenie między klientem a serwerem, dzięki któremu obie strony wymieniają się plikami w dowolnym czasie. Klient wyraża chęć nawiązania takiego magicznego połączenia poprzez wysłanie specjalnego żądania do serwera, a cały ten proces inicjalizacji nazywa się handshake. Przechodząc do sedna – w dowolnym momencie po pomyślnej inicjalizacji zarówno klient jak i serwer może wysłać kontrolny „ping”. Wtedy druga strona musi jak najszybciej odpowiedzieć wysyłając „pong”. Ten mechanizm to heartbeating! Wykorzystywany jest do sprawdzenia, czy ta-druga-strona jest nadal połączona. Czym jest ping/pong? To zwykła, kontrolna ramka danych. Pingi mają swój kod operacji 0x9, pongi 0xA.
Źródła: KLIK!, KLIK!
JAMstack
Ok. To pojęcie nie jest do końca widmem. Posiada nawet swoją stronę internetową. Jest ono jednak tak zakopane w internetach, tak słabo spopularyzowane, tak przytłumione, że blisko mu do widma. Definicja ze strony internetowej w moim kiepskim tłumaczeniu brzmi: „nowoczesna architektura web develpmentu oparta na JS po stronie klienta, reużywalnych API oraz prebuilt Markup (pomóżcie, jak to zgrabnie powiedzieć). Chodzi o budowanie statycznych stron, bez baz danych, bez backendu. JAM to skrót od 3 kluczowych warunków jam’owych apek: Javascript, APIs, Markup. Termin nie wiąże się z żadnymi konkretnymi technologiami, to tylko nowy sposób budowania „super wydajnych, tanich, bezpiecznych, developer-friendly” aplikacji. Front-End Developer Handbook 2017 prognozuje, że termin JAMstack ma zastąpić takie pojęcia jak „front-end apps”, „thick client apps”, „static apps”, „no backend app”, „SPA’s”. Wiem, że teraz rzadko wychodzę z domu i mogę być nie-w-temacie, jednak wydaje mi się, że ta prognoza trochę nie wyszła. Rok 2017 się powoli kończy, a pojęcie JAMstack nie jest bardziej popularne niż rok temu. Czyżby dlatego, że świat oszalał na punkcie Node.js, a JAMstack go wyklucza? A może dlatego, że ludziom podoba się React, JSX i nikt nie chce już pisać zwykłego HTMLa? Tak czy siak, pojęcie warto znać.
Źródła: KLIK!, KLIK!.
Konkretne artykuły o JAMstacku: KLIK!, KLIK!.
JAMstack Fundamentals: What, What And How – video / artykuł
Dajcie znać w komentarzach, czy znaliście te pojęcia!
