Going Headless: przypadki użycia i do czego to służy

Ten artykuł został uprzejmie wsparty przez naszych drogich przyjaciół ze Storyblok, przyjaznego bezgłowego CMS z edytorem wizualnym, zagnieżdżonymi komponentami i dostosowywanymi blokami treści dla stron internetowych i aplikacji. Dziękuję Ci!

Patrząc wstecz na lata tworzenia dla sieci, korzystałem z dziesiątek różnych narzędzi CMS, zarówno gotowych, jak i domowych. Wdrażam i buduję wiele witryn WordPress i wtyczek , a także rozszerzeń do witryn CMS z pełną obsługą w .NET. Ale dla mnie wszystko się zmieniło, gdy po raz pierwszy usłyszałem o bezgłowym, a teraz, po latach, nie mogłem czuć się bardziej komfortowo w bezgłowym ekosystemie .

Ten entuzjazm nie bierze się znikąd. Choć może wydawać się zniechęcające, aby zrozumieć wszystkie opcje bez głowy, dopracowywałem własną strategię dla różnych opcji bezgłowych w różnych środowiskach i dobrze zapoznałem się ze zwykłymi podejrzanymi w bezgłowej przestrzeni. Przejście na headless pomogło mi uniknąć wpadania na przeszkody spowodowane ograniczeniami większych systemów all-in-one.

Funkcjonalność podzielona na sekcje, dzięki której możesz dziś osiągnąć złożone cele i przygotować swoją aplikację do łatwej ewolucji w przyszłości, zapewnia mi spokój ducha. Z przyjemnością przyczyniłem się do udanych wdrożeń i iteracji usług internetowych zbudowanych na rozwiązaniach typu headless dla firm prywatnych i rządu stanu Kalifornia.

W tym artykule chciałbym podzielić się kilkoma przydatnymi wskazówkami i wskazówkami , których nauczyłem się przez te lata, mając nadzieję, że pomogą ci one zrozumieć świat bez głowy i znaleźć odpowiednich kandydatów do twoich projektów. Ale zanim zanurkujemy, musimy cofnąć się trochę w czasie, aby zrozumieć, co wnosi do stołu bezgłowy.

Przed Bezgłowym

Jeszcze kilka lat temu wydawało się, że nasze przepływy pracy skupiają się na szeregu narzędzi, stosów i technologii. W przypadku CMS korzystaliśmy głównie z narzędzi typu „wszystko w jednym”. Obejmowały one zarówno funkcje tworzenia treści, jak i przeglądania treści.

Użytkownicy tych narzędzi utknęli w interfejsie dostarczonym z zapleczem. Twoja zdolność do dostosowywania rzeczy była ograniczona. Możesz instalować wtyczki, ale wszystkie musiały być zbudowane dla twojego narzędzia. Możesz napisać niestandardowy kod — ale tylko w języku, na którym zbudowane jest Twoje narzędzie i w ramach jego ograniczeń.

Wszystko zmieniło się w ciągu ostatnich kilku lat, a bezgłowy CMS zyskał popularność w całej branży.

Renesans specjalistycznych narzędzi

Dzisiaj mamy rozkwit narzędzi, które specjalizują się w tworzeniu treści lub widokach prezentacji treści. Bezgłowy CMS skupia się na elemencie tworzenia treści i zapewnia sposób na podłączenie oddzielnego narzędzia do prezentacji treści. Brak frontendu skierowanego do użytkownika sprawia, że ​​jest bezgłowy i zapewnia elastyczność pracy z dowolnym narzędziem za pośrednictwem interfejsu API.

Możliwość zaprojektowania własnego frontendu od podstaw uwalnia wiele zespołów programistycznych. Możesz mieć zespół inżynierów cracku biegle w dostarczaniu zgrabnych, jednostronicowych aplikacji w Vue.js lub szybkim renderowaniu, kuloodpornych, generowanych statycznie witryn z 11ty. Wszystkie najnowsze frameworki do tworzenia stron internetowych są zaprojektowane do łatwej pracy z ustrukturyzowanymi danymi, które można dostarczyć z dowolnego bezgłowego CMS.

Bezgłowy CMS to skoncentrowane narzędzie. Ma mniejszą odpowiedzialność niż rozwiązanie typu „wszystko w jednym”. Punkty końcowe API dostarczane przez bezgłowy CMS zapewniają czysty rozdział między systemami, dzięki czemu można niezależnie wymieniać architektury frontonu lub backendu w miarę rozwoju sytuacji. Twój produkt się rozwija, poszerza się ekosystem narzędzi, pojawiają się nowe podejścia. Twoje wymagania dotyczące backendu i frontendu ulegną zmianie. Jeśli masz konfigurację bezgłową, będziesz w stanie łatwiej się dostosować, ponieważ Twój front i backend są już wyraźnie oddzielone przez API i możesz je aktualizować niezależnie.

Czy Headless jest dla mnie odpowiedni?

Przede wszystkim headless zapewnia elastyczność, której możesz potrzebować, aby sprostać trudnym wymaganiom. Osiągnięcie swoich celów może być trudne, jeśli musisz mocno zmodyfikować produkt typu „wszystko w jednym”. Połączenie narzędzia bez głowy z mniejszym, innym lub domowym interfejsem może być najłatwiejszym sposobem na dostarczenie pożądanych projektów i przepływów użytkowników.

• Jeśli chcesz dostroić każdy etap procesu realizacji zakupu , możesz w tym celu skorzystać z opcji handlu bez głowy,
• Jeśli chcesz mocno zoptymalizować czas do pierwszego bajtu , możesz użyć statycznego generatora witryn, który odbudowuje zawartość po zmianie w oparciu o bezgłowy interfejs API CMS,
• Jeśli hostujesz własne narzędzia i jesteś ostrożny w kwestii bezpieczeństwa, możesz zablokować swoje środowisko autorskie za zaporą ogniową i bezmyślnie korzystać z prostszego frontendu opartego na Jamstack,
• Jeśli udostępniasz tę samą zawartość różnym klientom, takim jak aplikacje internetowe, natywne lub widżety innych firm, możesz je zbudować w taki sposób, aby wszyscy komunikowali się bezmyślnie za pośrednictwem tego samego CMS.

Jeśli możesz bezbłędnie spełnić wymagania swojego projektu za pomocą narzędzia typu „wszystko w jednym”, to opcje bezgłowe są prawdopodobnie dla ciebie trochę przesadą. W ten sam sposób, jeśli Twój zespół jest doskonale zadowolony i dobrze zorientowany w Twoim obecnym rozwiązaniu typu „wszystko w jednym”, tak naprawdę nie musisz się martwić o dzielenie oprzyrządowania frontowego i backendowego. Jeśli jednak zamiast tego napotykasz ograniczenia swoich narzędzi, to bez głowy pozwoli Ci bezpośrednio zająć się problemami.

Przykład: Bezgłowy e-commerce

Przyjrzyjmy się konkretnemu wyborowi bez głowy: możesz zintegrować istniejącą platformę eCommerce, taką jak Shopify, jako kompletny przepływ, który przejmuje cały proces kasy, lub możesz skorzystać z opcji bez głowy, którą zapewnia również Shopify.

• W pierwszym przypadku Twój projekt będzie w dużej mierze opierał się na szablonach Shopify i gotowych funkcjach , więc dostosowanie przepływu realizacji transakcji będzie możliwe, ale dość ograniczone.
• W tym drugim przypadku możesz zaprojektować przepływ kasy w dowolny sposób, a Shopify będzie polegać jedynie na wykonaniu transakcji finansowej.

Istotna różnica polega na tym, że opcja bez głowy będzie wymagała zbudowania każdego widoku , który widzi użytkownik. Po raz kolejny, jeśli brzmi to jak kłopot bez korzyści, prawdopodobnie nie potrzebujesz rozwiązania bez głowy.

Zespół, który potrzebuje wersji bez głowy, z zadowoleniem przyjmie wolność, jaką zapewnia. Twój projekt nie będzie miał ograniczeń i będziesz mógł kontrolować każdy piksel w każdym widoku. Będziesz mieć pełną kontrolę nad całym kodem wykonywanym na urządzeniach Twoich użytkowników, dzięki czemu możesz śledzić, optymalizować i przyspieszać dosłownie każdą interakcję.

Jednocześnie nadal pozostawiasz przetwarzanie transakcji swojemu bezgłowemu rozwiązaniu eCommerce, więc czerpiesz korzyści z ich systemu zaplecza.

Najważniejsze jest to, że jeśli zmagasz się z wąskimi gardłami w swoim obecnym rozwiązaniu eCommerce — czy to ciężki interfejs, złożony interfejs użytkownika, czy po prostu niedostępny projekt — wtedy opcja bez głowy ułatwi Twojemu zespołowi rozwiązanie tych problemów. Podobnie, jeśli wydaje się, że ułatwi to Twojemu zespołowi zwiększenie ścieżki konwersji dzięki szybszemu i płynniejszemu wdrażaniu nowych funkcji, warto rozważyć również opcję bezgłową.

Unikanie blokady za pomocą jednej platformy

Patrząc na obecny stan front-endu, rozdzielenie narzędzi do tworzenia i dostarczania treści jest najbezpieczniejszym sposobem projektowania rzeczy w świecie, w którym opcje narzędzi frontonu i zaplecza stale się rozszerzają. Nierzadko zdarza się, że środowiska tworzenia i czytania mają różne zestawy wymagań, więc możliwość wyboru narzędzi, które zajmują się nimi osobno, daje lepsze możliwości dla obu stron.

Konfiguracje oparte na Jamstack są włączane przez interfejsy API, więc często są powiązane z bezgłowym CMS. Dokonanie bezgłowego wyboru nie wymaga jednak front-endu Jamstack . Oczywiście, jeśli chcesz, nadal możesz uruchomić kod po stronie serwera.

Na przykład pomogłem zbudować kilka witryn działających na Node.js i Express korzystających z back-endowych API, takich jak Wordnik.com i ten popularny wzorzec działa płynnie. Dostęp do danych za pośrednictwem interfejsów API umożliwia porzucenie kodu po stronie serwera w środowisku produkcyjnym, dzięki czemu możesz łatwo zastosować podejścia po stronie klienta, takie jak Jamstack, jeśli ma to sens w Twoim projekcie.

Problem z rozwiązaniami typu „wszystko w jednym” polega na tym, że każdy z nich ma w sobie wiele zobowiązań . Na przykład musisz zaangażować się we wspieranie środowiska baz danych i programowania lub wybierać spośród dostawców SaaS, którzy to robią; również zmiany w projekcie będą musiały nastąpić w ramach dostępnych motywów i wtyczek.

Bez głowy wyrywamy się z zamknięcia na jednej platformie. Jeśli więc potrzebujesz nowego front-endu dla swojej strony internetowej, chcesz usunąć kosztowną infrastrukturę produkcyjną i użyć statycznych generatorów witryn, a może chcesz zmienić system CMS bez przebudowy całego front-endu od zera — w porównaniu z alternatywami , możesz to wszystko osiągnąć przy znacznie mniejszym tarciu, gdy korzystasz z opcji bezgłowej.

Spójrzmy na prosty przykład. Wyobraź sobie, że Twoja organizacja wymyśla nową inicjatywę i nowy projekt, a przepływy są tworzone od podstaw w celu zaspokojenia nowych potrzeb użytkowników. Nagle, aby spełnić te wymagania, konieczne jest zmontowanie nowego stosu technologii.

Wybór opcji bezgłowej zapewni Twoim produktom lepszą szansę na długowieczność i znacznie ułatwi płynne przenoszenie treści do wielu kanałów dostawy.

“

W takich przypadkach musisz poszukać idealnego, gotowego rozwiązania, które idealnie pasuje do Twoich potrzeb, lub złamać niektóre wymagania dotyczące projektu i przepływu użytkowników, aby działało wystarczająco dobrze. Ale jeśli twój projekt lub wymagania dotyczące wydajności są surowe, może być łatwiej osiągnąć te cele, jeśli nie masz głowy.

Najważniejsze jest to, że istnieje wiele przypadków użycia przy wyborze opcji bezgłowej, która zapewni Twoim produktom lepszą szansę na długowieczność , a także znacznie ułatwi płynne przenoszenie treści do wielu kanałów dostawy. Możliwość korzystania z treści w postaci uporządkowanych danych pozwala im rozwijać się we własnej witrynie, w natywnych aplikacjach i być dystrybuowana do źródeł zewnętrznych.

Nie wszystko musi być bez głowy

Może się wydawać, że bezgłowy jest zawsze lepszą opcją, ale tak nie jest. Jeśli w swoim obecnym projekcie nie przejmujesz się zbytnio projektami i opcjami technicznymi opisanymi powyżej lub po prostu potrzebujesz działającej strony internetowej, która wykonuje pracę dzisiaj, prawdopodobnie nie będziesz potrzebował tak bardzo headless.

Oczywiście szybkość od pomysłu do dostawy jest ważna, więc ponieważ jesteś o kilka kliknięć od przyzwoicie wyglądającej strony internetowej bez odpowiedniego wsparcia technicznego z Twojej strony, możesz odłożyć opcje bez głowy na później. Możesz skupić się na optymalizacji witryny i długowieczności, gdy poczujesz, że Twój pomysł może zadziałać.

Jak bezgłowe wybory pomagają wyjść z pomyłek

Aktualizacja zaplecza

Niebezpieczeństwa związane z cenami na użytkownika

Jakiś czas temu pomogłem założyć system blogowania, z którego korzystałoby dziesiątki autorów. Byliśmy pod ogromnym wrażeniem zestawu funkcji jednego z bezgłowych dostawców CMS, wybraliśmy go dla bezgłowego CMS i cieszyliśmy się, że zbudowaliśmy na nim frontend, który płynnie wtapiał się w nasz pakiet produktów. Ostatecznie firma zdecydowała, że ​​liczba autorów powinna zostać zwiększona do kilku tysięcy.

Większość hostowanych rozwiązań CMS nie publikuje struktury cen dla tak dużej liczby użytkowników. Kiedy zapytaliśmy o koszt dalszego prowadzenia tego na tej samej platformie, odpowiedź nam się nie spodobała. Aby ten system nadal miał sens biznesowy, musieliśmy wymienić nasz CMS. Udało nam się dokonać zamiany bez złomowania frontendu ze względu na bezgłową architekturę.

Ograniczanie API

Tak wiele startupów skupiających się wyłącznie na środowisku autorskim jest w stanie tworzyć piękne produkty z interfejsami API przyjaznymi dla programistów. Airtable to przykład innowacji w arkuszach kalkulacyjnych dzięki przyjaznemu dla użytkownika interfejsowi użytkownika w połączeniu z czystym doświadczeniem programisty za pośrednictwem dobrze udokumentowanego interfejsu API.

Zbudowałem kilka przydatnych prototypów, w których wprowadzałem zeskrobane dane do Airtable, gdzie były one edytowane przez ekspertów, a następnie wykorzystywałem ich interfejsy API do obsługi widoków treści działających w witrynie głównej oraz w osadzaniach działających na witrynach stron trzecich. Podczas konfigurowania systemu odczytu przeciągnąłem dane Airtable do systemu gotowego do produkcji, który mógłby obsłużyć duże obciążenie ruchem i przez jakiś czas działało to dobrze.

Zacząłem jednak mieć problemy z zapisem danych. Połączenia kończyły się niepowodzeniem z powodu sztywnego limitu 5 żądań na sekundę. Osiągnięcie tego limitu powoduje 30-sekundową pełną blokadę żądania API. Próbowałem przesłać dane z systemu rozproszonego, więc dodałem przepustnice i podzieliłem rzeczy na osobne bazy.

Wraz z rozwojem systemu i wzrostem ilości danych przerastaliśmy to narzędzie. Udało mi się rozwiązać ten problem, wbudowując podstawowe funkcje edycji danych do systemu opartego na instancji AWS DynamoDB, która czytała z airtable. Udało nam się szybko zamienić zgrabne funkcje interfejsu użytkownika Airtable na większą skalę i niższe miesięczne rachunki SaaS.

To kolejny przykład na to, jak czysta separacja między frontendem a backendem zapewniana przez interfejsy API narzędzi do tworzenia bezgłowych treści pozwala precyzyjnie kierować problemami.

Aktualizacja frontendu

Błyszczące nowe ramy

Organizacje, które istnieją już od jakiegoś czasu, często mają problem z koniecznością obsługi systemów produkcyjnych zbudowanych na różnych stosach technologii . Istnieje ciągła presja na homogenizację oprzyrządowania, ale także na innowacje. Byłem częścią zespołu, którego zadaniem było budowanie widoków i widżetów, które integrowałyby się z istniejącymi produktami opartymi na bezgłowym CMS. Świetnie się bawiliśmy, szybko budując prototypy za pomocą różnych lekkich narzędzi frontendowych.

Przeprowadziliśmy wewnętrzny konkurs, aby zobaczyć, który inżynier w zespole frontendowym może stworzyć najlepszy frontend na podstawie treści dostarczonych z punktów końcowych interfejsu API CMS bez głowy. Jedna prezentacja miała najlepszy zestaw funkcji i najmniejszą ilość kodu, więc programiści dostali projekt i dostarczyli produkt, budując go za pomocą Riot.js.

Riot.js to fajna mała biblioteka, która zawiera mnóstwo funkcji w niewielkim rozmiarze. Pomaga pisać oparte na danych komponenty pojedynczego pliku, takie jak Vue.js. Kiedy twórca tego frontendu opuścił firmę wkrótce po wydaniu wersji 1.0, zespół stracił jedyną osobę z entuzjazmem dla tej biblioteki.

Czasami przejście od ekscytującego, nowego, szybkiego schematu rozwoju do długu technologicznego następuje bardzo szybko.

“

Na szczęście oddzielona natura bezgłowej architektury CMS zapewnia elastyczność zmiany frontendu bez dotykania zaplecza . Udało nam się przepisać kod front-endu i zamienić zaktualizowane komponenty front-endu na podstawie różnych bibliotek, które były częściej używane w innych projektach.

Surowa prędkość

Uwielbiam projekt Ghost. Byłem pierwszym subskrybentem, ponieważ fajnie było zobaczyć rozwiązanie podobne do WordPressa zbudowane na Node.js. Szanuję tę organizację za oferowanie usługi opartej na narzędziach open source, które stale udoskonalają. Byłem bardzo zadowolony z tego narzędzia, kiedy używałem go na moim osobistym blogu.

Był jednak jeden aspekt rozwiązania, który nie był doskonały. Czas do pierwszego bajtu na moim blogu prowadzonym przez Ghost był zbyt wolny. Ponieważ mogłem pobrać całą zawartość posta za pomocą interfejsu API, mogłem skonfigurować własny, statycznie generowany frontend na S3 + Cloudfront, który wykorzystywał całą zawartość posta, którą napisałem w Ghost, ale miał szybszy czas do pierwszego bajtu.

Bezgłowy CMS jako usługa

Istnieje wiele firm zajmujących się oprogramowaniem jako usługą, które poszły na całość bez głowy. Rejestracja u jednego z tych dostawców może natychmiast zapewnić przyjazne środowisko edycji treści i czyste punkty końcowe API do pracy. Oto szybkie porównanie kilku z nich, z których wszystkie mają bardzo tanie plany podstawowe i laserowe skupienie na bezgłowym doświadczeniu CMS.

Wszystkie te usługi mają solidny zestaw podstawowych funkcji . Wszystkie obejmują hosting zasobów statycznych, zapisaną historię wersji i dobrze udokumentowaną obsługę lokalizacji. Różnią się interfejsem użytkownika tworzenia treści i funkcjami API.

Ekscytujące wzory bez głowy

Korzystanie z CMS opartego na GitHub

Możliwość korzystania z zarządzania użytkownikami, kontroli wersji i przepływów pracy zatwierdzania w GitHub to duże zalety. Nie trzeba zakładać nowych kont w nowych systemach. Możliwość przeglądania historii recenzji wraz z aktualizacjami treści jest fajna.

Istnieją różne odmiany narzędzi CMS opartych na GitHub. Ten był szybkim sposobem na uruchomienie witryn z dokumentacją: Spacebook można zintegrować z Netlify, aby uzyskać czystszy interfejs do edycji przecen lub używać go bezpośrednio na GitHub.

Funkcje podglądu, które są teraz wbudowane w edytor sieciowy GitHub, sprawiają, że niektóre z tych narzędzi są bardziej dostępne dla osób, które nie znają języka HTML. Uwielbiam opcję różnic z bogatymi widokami, w której GitHub pokazuje zmiany przecen w trybie pełnego podglądu.

Jest to doskonała lista 85 narzędzi CMS, która pozwala sortować, czy są one oparte na GitHub, czy nie.

Interfejsy API dla znanych narzędzi

Twoja instalacja WordPress zawiera punkty końcowe API, dzięki czemu możesz nadal korzystać z narzędzi do tworzenia, które Twój zespół ma doświadczenie w bezgłowy sposób. WordPress ma ładną dokumentację dla swojego REST API. Jest to włączone w nowych instalacjach WordPress, więc po uruchomieniu nowego środowiska autorskiego WordPress możesz zacząć czytać JSON z https://example.com/wp-json/wp/v2/posts .

Strona ustawień WordPress zawiera pole usługi aktualizacji, w którym możesz wprowadzić adresy URL usług, które chcesz pingować po zmianie treści. Jest to idealne rozwiązanie do uruchamiania narzędzia bezserwerowego w celu pobrania najnowszych aktualizacji. WordPress v5 ma to pole w sekcji Pisanie w ustawieniach

Łączenie źródeł danych

Korzystanie z bezgłowych narzędzi dla stanu Kalifornia pomogło nam stworzyć witryny reagowania kryzysowego, które podniosły poprzeczkę wydajności. Mieliśmy pełną kontrolę nad architekturą frontendu i nadal byliśmy w stanie pozwolić twórcom na używanie znanych narzędzi autorskich.

Używamy WordPressa bez głowy , pisząc do GitHub za pośrednictwem FAAS. Zapisujemy również inne źródła danych do repozytorium i uruchamiamy statyczne kompilacje generatora witryn przy każdej zmianie. Przykładami danych, które są zapisywane w git oprócz oryginalnej treści redakcyjnej, są dane, które zmieniają się tylko raz dziennie, takie jak statystyki górnej linii i nasze przetłumaczone przez człowieka wersje każdej strony.

Wykorzystanie akcji GitHub jako wyzwalaczy kompilacji pozwoliło nam zintegrować kilka różnych źródeł danych z witryną, dzięki czemu uzyskaliśmy szybkie publikowanie i niewielki ślad infrastruktury produkcyjnej. Mniejsza infrastruktura produkcyjna pozwala nam swobodnie oddychać, gdy natrafimy na duże skoki ruchu związane z rządowymi zapowiedziami pandemii.

Część architektury repozytorium WordPress -> FAAS -> GitHub została stworzona przez Carter Medlin. Połączył ten potok od podstaw w kilka dni, podczas gdy my projektowaliśmy i budowaliśmy frontend witryny. Działa to na bezserwerowej funkcji MS Azure, więc koszty infrastruktury i utrzymania są niskie. Pobiera pingi z opisanej wcześniej usługi aktualizacji WordPress, pobiera json z API WordPress i zapisuje nową zawartość w GitHub. Kod tego bezserwerowego punktu końcowego jest widoczny w serwisie GitHub.

Nasze boty ciężko pracują, publikując wszystkie aktualizacje treści , gdy otrzymują pingi z WordPressa. To działanie tworzy łatwy do przeglądania dziennik każdej aktualizacji i możliwość cofnięcia zmian za pomocą zwykłych procesów GitHub.

Budowanie frontendu tej witryny za pomocą generatora statycznych witryn 11ty było szybkie, przyjemne i działało idealnie. Odnotowujemy duże skoki ruchu na wiadomościach związanych z pandemią, a świadomość, że mamy statyczny interfejs użytkownika, zmniejsza ryzyko, gdy liczba jednoczesnych użytkowników zaczyna rosnąć i publikujemy wiele aktualizacji treści.

Podoba mi się, jak społeczność 11ty koncentruje się na wydajności i dostępności dzięki swoim rankingom społeczności i lekkiej architekturze. Ważne jest, aby narzędzia stworzone przez państwo działały dla wszystkich Kalifornijczyków. Chcemy, aby wszystko działało na dowolnym urządzeniu w warunkach niskiej przepustowości i wspierało wszystkie technologie pomocnicze. To całkiem fajne, że możemy korzystać z narzędzi takich jak 11ty, które ułatwiają dostarczanie szybkich i dostępnych witryn. Używamy komponentów webowych w interfejsie, aby zapewnić dodatkowe funkcje, jednocześnie utrzymując niewielką wagę kodu.

Rozważania przy dokonywaniu wyborów bez głowy

Jesteś podekscytowany możliwościami, jakie dają Twojemu zespołowi narzędzia bezgłowe? Liczba dostępnych opcji może być przytłaczająca. Oto lista funkcji, które mogą pomóc w ograniczeniu opcji:

Funkcje środowiska autorskiego

• Łatwość tworzenia dokumentów
• Łatwość dodawania uporządkowanych danych
• Opcje układu
• Funkcje podglądu
• Przepływy pracy zatwierdzania treści

Funkcje interfejsu API treści

• Jakie zapytania są dostępne
• Jak szczegółowa jest struktura treści
• Czy są jakieś ograniczenia dostępu do danych (twarde limity Airtable REST API)
• Skalowalność : czy musisz umieścić CDN przed interfejsem API treści?
• Łatwość dodawania lokalizacji
• Wydobycie treści, co się stanie, jeśli zmienisz plany, jak trudne będzie wydobycie wszystkich danych?

Koszt

• Czy płacisz za użytkownika za rozwiązania hostowane?
• Zarządzasz oprogramowaniem open source, które instalujesz we własnym środowisku?
• Czy konta użytkowników są łatwe w administrowaniu?
• Czy możesz zintegrować się z istniejącymi rozwiązaniami jednokrotnego logowania?
• Czy produkt przeszedł audyty bezpieczeństwa, czy zawiera uwierzytelnianie dwuskładnikowe ?

Kontrola źródła/przepływy zatwierdzania

• Czy zawartość jest wersjonowana , dzięki czemu można cofnąć się do wcześniejszych wersji i śledzić, co zostało opublikowane i jakie zmiany zostały wprowadzone i kiedy?
• Czy możesz udostępniać nowe wersje treści przed ich opublikowaniem? Czy możesz ograniczyć dostęp do tych podglądów?

Zarządzanie plikami statycznymi

• Jak łatwo Twoi autorzy mogą dodawać nowe obrazy, pliki PDF itp.?
• Łatwość łączenia plików przesłanych przez autora z procesami optymalizacji obrazu?

Dokąd zmierza Bezgłowy

Kiedy przyjrzysz się uważnie krajobrazowi bez głowy, przekonasz się, że narzędzia bez głowy celowo ograniczają ich zakres funkcjonalny i zapewniają sposoby integracji z większymi systemami. Rozdzielenie określonych funkcji jest korzystne, gdy systemy stają się bardziej złożone. Po prostu łatwiej jest dokonać konkretnych wyborów, które ograniczają koszty, bezpieczeństwo, konserwację i wymagania hostingowe w przypadku większego kodu, gdy pracujesz z mniejszymi, ukierunkowanymi narzędziami.

Warto zauważyć, że opcje bez nagłówka zwykle wymagają samodzielnego napisania kodu . Ponieważ jednak nakładki są w coraz większym stopniu zbiorem gotowych komponentów i często całym gotowym projektem wypełnionym własnymi danymi, nie powinno być zbyt zarozumiałe, aby oczekiwać więcej sposobów łączenia i dopasowywania specjalistycznych narzędzi oraz bezproblemowej integracji opcje bezgłowe bez samodzielnego pisania kodu.

Idealnym zapleczem dla projektu może być po prostu subskrypcja SAAS lub instalacja projektu open-source. Może to integrować się bezkodowo z gotowym frontendem, który spełnia wszystkie Twoje potrzeby. Widzę, że Stackbit już łączy bezgłowy CMS z nakładką bez kodu. Mogę skonfigurować nową witrynę za pomocą narzędzia do tworzenia stron kodowych WYSIWYG firmy Stackbit, a następnie wybrać zestaw opcji CMS bez nagłówka od różnych dostawców, aby zarządzać pełnymi danymi witryny.

W tym artykule omówiliśmy kilka przypadków użycia, w których bycie bez głowy pomogło firmom, dla których pracowałem, poradzić sobie ze zmianami. Bezgłowe wybory są kuszące , niezależnie od tego, czy jesteś zainteresowany elastycznością architektury aplikacji, kontrolą doświadczenia użytkownika, czy też starannym przemyśleniem trwałości usługi.

Jestem podekscytowany, widząc, jak ta przestrzeń nadal się rozwija i będę nadal szukać sposobów na wykorzystanie tych opcji, aby dostarczać lepsze produkty i ułatwiać mi pracę jako programista.

Dalsze zasoby

• Headless CMS, doskonała lista 85 narzędzi CMS, która pozwala sortować, czy są one oparte na GitHub, czy nie.
• „Jak stworzyć bezgłową witrynę WordPress na Jamstack”, Sarah Drasner i Geoff Graham
• Handel bez głowy, Shopify
• „GoTrue JS: Uwierzytelnianie witryn statycznych za pomocą zaledwie 3 KB JS”, ​​Divya Sasidharan, Netlify
• Doświadczenie edycji dla stron Jamstack, Stackbit
• API integracji Wordpress, CAdotGov, GitHub

Ten artykuł został uprzejmie wsparty przez naszych drogich przyjaciół ze Storyblok, przyjaznego bezgłowego CMS z edytorem wizualnym, zagnieżdżonymi komponentami i dostosowywanymi blokami treści dla stron internetowych i aplikacji. Dziękuję Ci!