Software Craftsmanship Saturday vol. 33

1. Nowa Metoda SEARCH zaproponowana jako rozwinięcie HTTP

Propozycja dodania nowej metody w HTTP to nie jest mała rzecz – ostatni raz coś takiego wydarzyło się wraz z opublikowanie HTTP/1.1 w roku 1999, ponad 20 lat temu. Dlatego też informacja o opublikowaniu przez IETF – Internet Engineering Task Force – proposala dotyczącego dodania do protokołu (obok dobrze znanych metod pokroju GETa i POSTa, czy też mniej znanych TRACE i CONNECT) metody SEARCH z pewnością jest dużym wydarzeniem. Wydarzeniem bliskim memu sercu ponieważ wielokrotnie przy pracy z RESTowymi API musiałem obchodzić ograniczenia HTTP – ograniczenia, które SEARCH ma zniwelować.

Wyobraźcie sobie, że macie zaprojektować API pozwalające na wygodne wyszukiwanie danych za pomocą kilku różnych parametrów – niech to będzie choćby API geolokalizacyjne, gdzie dana encja może być wyszukana np. po odległości od konkretnych koordynat, ale również np. po typie. W momencie kiedy tych parametrów pojawia się dużo, bardzo trudno modeluje się je za pomocą „query parametrów” GETa – niestety, link okazuje się być wtedy mocno nieczytelny. Nieco lepiej sprawa wygląda jeśli użyjemy metody POST i nasze zapytanie stanie się JSONem, czego prekursorem (a przynajmniej wokalnym adwokatem) swego czasu był Dropbox. Niestety, również to podejście, mimo swojej niewątpliwie lepszej ekspresywności, posiada masę problemów, wśród których warto wymienić choćby fakt braku wsparcia dla cache.

SEARCH można rozumieć jako formę GETa posiadającego również “ciało”. Całość przydatna będzie nie tylko w opisanym przeze mnie powyżej przypadku, ale również jako standardowy protokół transferowy dla zdobywającego coraz większą popularność GraphQL – jego twórcy już ostrzą sobie zęby na jego użycie.

GraphQL znany jest z tego, że dość frywolnie podchodzi do używania metod GET i POST

Proponowana obecnie implementacja ma bazować na implementacji SEARCH udostępnionej w ramach WebDAV (rozszerzeniu HTTP, pozwalającym na zarządzanie i kontrolę wersji plików na serwerze WWW). Ma to sprawić, że istniejące serwery Proxy powinny być w stanie posłużyć się bez większych rewolucji.

Oczywiście, dodanie przed twórcami implementacji czai się trochę problemów (bardzo dobrze opisanych w artykule od HTTP Toolkit), a adopcja całości pewnie zajmie chwilę, osobiście bardzo czekam. Jeśli wszystko pójdzie zgodnie z planami twórców, uzyskamy bardzo przydatną opcję przy projektowaniu API.

PS: W temacie HTTP – Firefox dodał wsparcie HTTP/3 w swoich wersjach rozwojowych.

Źródła:

2. Amazon publikuje fork OpenSearch, Elastic sprzymierza się z Kafką

Zmiana licencji ElasticSearch była jednym z najbardziej kontrowersyjnych ogłoszeń pierwszego kwartału 2021 roku. Dla tych którzy nie pamiętają – całość poszła o zmianę licencji tego bardzo popularnego silnika wyszukiwania pełnotekstowego opartego na Apache Lucene – całość opisywaliśmy zresztą już dwukrotnie: najpierw informując o całym zajściu, potem zaś relacjonując reakcje społeczności, wśród których na pierwszy plan wyszła zapowiedź forka projektu tworzonego przez Amazon.

Rzeczony fork ukazał się w tym tygodniu, udostępniając otwarte (w rozumieniu – oparte na licencji Apache) OpenSearch (oparte na Elasticsearch 7.10.2) oraz OpenSearch Dashboards (oparte o zbudowany na Elasticsearchu dashboard Kibana 7.10.2). Nie mogę pozbyć się wrażenia, że Amazon celowo dał w nazwie nowych projektów Open, żeby zagrać na nosie Elasticowi. Projekt rozwijany ma być przez społeczność, a oprócz Amazona w projekt zaangażowane są Red Hat, SAP, Capital One, oraz Logz.io. Wszystkie usługi w ramach AWS zostaną oparte właśnie o tą dystrybucję i przejdą stosowny rebranding.

Bo wiecie, Amazon robi to z miłości do otwartego oprogramowania i w ogóle…

Oczywiście, to że OpenSearch zyskał nieco światła reflektorów nie oznacza wcale, że Elastic.co złożył broń. Sprzymierzył się on z innym znaczącym graczem – zajmującym się rozwojem Kafki Confluentem. Obie firmy zapowiedziały strategiczne partnerstwo, którego pierwszym owocem jest oficjalny “connector” łączący Elastic Cloud i Confluent Cloud. Ciekawe czy przyszłość, która nam się rysuje, to właśnie walka “zintegrowanych” chmur typu AWS czy Azure z luźno powiązanymi, wyspecjalizowanymi rozwiązaniami typu MongoDB Atlas czy wspomniana wyżej dwójka. Temat jest ciekawy i jeśli ktoś jest nim zainteresowany to Corey Quinn (którego tekst zresztą znalazł się w naszej poprzedniej edycji) popełnił swego czasu ciekawy esej na temat tego jakie opcje mają firmy chcące konkurować z dużymi chmurami.

Źródła:

3. Procesor M1 nie daje o sobie zapomnieć

A na zakończenie coś dla fanów jabłek – ale zaskakująco nie tylko ich.

Tak jak początkiem tego roku spór Elastic vs AWS rozpalał wyobraźnie, tak z pewnością końcówka zeszłego należała do procesorów M1 zaprezentowanych przez Apple. Wszyscy zastanawiali się jak to możliwe, że są
aż tak wydajne, pojawiła się też choćby strona listująca poziom kompatybilności oprogramowania z tą architekturą procesora.

Dla wielu programistów problematycznym przy podejmowaniu decyzji o przejściu na nową architekturę był fakt, że jednym z programów nie tylko nie działających na M1 natywnie, ale również posiadającym problemy z środowiskiem translacyjnym Rosetta 2 był niezbędny dla wielu Docker. Na szczęście jeśli to było dla was główną przeszkodą przed zaopatrzeniem się w komputery napędzane krzemem od Apple to mamy przyjemność poinformować, że w zeszły czwartek Docker ogłosił pierwsze oficjalne wydanie na M1.

Całość okazała się możliwa dzięki temu, że w lutym Go (będące głównym językiem programowania używanym w ramach Dockera) wypuściło swoje wsparcie dla nowych Maców. Jeżeli dodać do tego fakt, że Homebrew również jest już dostępne na nowej platformie, coraz mniej przeszkód stoi przed osobami chcącymi zaopatrzyć się w nowiutkie komputery od Apple…

…zwłaszcza, że okazuje się iż sprzęt ten staje się coraz bardziej uniwersalny. Otóż do jądra Linuxa trafiła poprawka umożliwiająca uruchomienie tego systemu na procesorach z rodziny M1. Ze względu na fakt, że Apple nie wypuściło pełnej specyfikacji swoich procesorów, całość pracy opiera się na inżynierii wstecznej. Wspomniana poprawka jest pierwszym krokiem w tym prawdopodobnie żmudnym procesie – na ten moment np. nie udało się jeszcze rozpracować jak działa GPU, przez co całość obsługiwać można jedynie z poziomu terminala, nie działa też większość sterowników.