Przed użyciem zapoznaj się z treścią Regulaminu lub skonsultuj się z Moderatorem lub Adminem,
gdyż każde Forum niewłaściwie stosowane zagraża Twojemu życiu literackiemu i zdrowiu psychicznemu.


Dialogatornia - kwalifikacje do warsztatów z pisania dialogów

Alicja w Krainie Czarów, czyli backend z Headless CMS

Chcesz pokazać innym swój punkt widzenia? Tu możesz to zrobić

Moderatorzy: Poetyfikator, Moderator, Weryfikator, Zasłużeni przyjaciele

Awatar użytkownika
P.Yonk
WModerator
WModerator
Posty: 1036
Rejestracja: sob 17 cze 2017, 20:08
OSTRZEŻENIA: 0
Lokalizacja: cukry.ozdobne.występy
Płeć: Mężczyzna

Alicja w Krainie Czarów, czyli backend z Headless CMS

Postautor: P.Yonk » śr 19 gru 2018, 22:13

Popełniłem takie coś, bo kazali. Nie jest za bardzo techniczny, ale znów dla innych może się okazać nieco hermetyczny. Mam nadzieję, że chociaż zabawny.

---

Wielu developerów, zespołów czy firm - przynajmniej raz stawało przed problemem, czego użyć, by zapewnić szybki i bezpieczny dostęp do danych, oraz umożliwić łatwe ich wprowadzanie nawet osobom bez specjalistycznego doświadczenia. W naszej firmie często stajemy przed takim dylematem. Mamy spore doświadczenie z wieloma systemami zarządzania treścią (CMS), tworzyliśmy też wielokrotnie własne rozwiązania, dopasowane do potrzeb klienta. Nie mogło być inaczej i teraz.



Warunki brzegowe


„Oh dear! Oh dear! I shall be too late!”



Pierwszy problem do rozwiązania - nie ma czasu na dedykowany system zarządzania treścią, szczególnie gdy zespół mały z jednym backendowcem, a do tego koledzy frontendowcy wymagają prostych URL’i do API.


Drugi - dane będą pobierane i udostępniane poprzez aplikację na smartfonach zarówno z iOS, jak i Androidem. Dane muszą być osiągalne dla aplikacji, choćby użytkownik był poza zasięgiem sieci, bez dostępu do Internetu. Nawet gdy już będzie miał dostęp, to przepustowość łącza, może być bardzo ograniczona, dlatego dostarczona treść, czy dane, nie mogą być bogate multimedialnie, z niepotrzebnymi informacjami. Oczywiście sama aplikacja wraz z danymi, nie mogą zająć całej dostępnej pamięci urządzenia.


Problem ten implikuje sposób i format w jaki będą dostarczone dane - nie może to być sformatowany dokument HTML, bo wystarczyło by utworzyć zwykłą stronę, ale wtedy nie będzie łatwo przechować danych w pamięci urządzenia. Poza tym dostajemy sporo nadmiarowej informacji przeznaczonej dla przeglądarki, np informacje o stylach, czcionce, kodowaniu, itp - nie mówiąc o samej strukturze dokumentu z całą gamą znaczników HTML. Nikogo nie trzeba chyba przekonywać do formatu JSON. W naszym przypadku ten lekki format wymiany danych spełnia postawione warunki.


Pozostaje tylko wybrać system CMS łatwy w obsłudze, umożliwiający dostarczanie danych w takim formacie.



Przegląd rozwiązań


„Would you tell me, please, which way I ought to go from here?”
„That depends a good deal on where you want to get to.”



Aktualnie na rynku dostępna jest cała gama systemów zarządzania treścią, dostępnych na różne platformy, różne środowiska programistyczne. Od darmowych po płatne, od napisanych w PHP, przez JavaScript, do C++ czy Java. Moje osobiste doświadczenie wymusiło tutaj koncentrację na rozwiązaniach opartych na dwóch pierwszych językach programowania, gdzie wybór jest znacznie większy.


Czego nie możemy użyć?


Przede wszystkim klient mając decydujący głos w tej sprawie, kategorycznie nie życzył sobie najpopularniejszych rozwiązań, takich jak Wordpress, czy Joomla. Więc te dwa mamy z głowy. Ale nadal do wyboru jest cała gama: TYPO3, Drupal, eZ Publish, Contao, October, Grav. Mógłbym tak cały wieczór. Każdy z nich ma rzeszę fanów wśród programistów, jak i użytkowników. Każdy z nich można teoretycznie dostosować do naszych potrzeb. Jednak wszystkie były projektowane do tworzenia i dostarczania sformatowanej i ostylowanej treści, przede wszystkim pod strony internetowe, portale, blogi. My zaś mamy dostarczyć wyłącznie treść, więc dostosowywanie Standardowych CMS'ów do tego wymogu, to jak kupowanie kombajnu, by potem wymontować z niego szereg funkcjonalności, dodać inne i tak jeździć na zakupy do marketu. Nie chodzi o to, że są złe, tylko nie były projektowane do tego, co potrzebujemy. Każdy z nich może pracować jako headless CMS, lecz to wymaga dodatkowych wtyczek, albo zaprojektowania odpowiedniej templatki. Po co, skoro istnieją CMS'y zaprojektowane jako providery danych?



„Off with her head! Off—”


Zwykły CMS daje nam trzy rzeczy:


  1. Sposób na przechowywanie danych.


  2. CRUD UI*.


  3. Sposoby prezentacji danych.


Headless CMS daje nam:


  1. Sposób na przechowywanie danych.


  2. CRUD UI*.


  3. Interfejs API do danych.


„Głowa”, której się pozbywamy, to widoki ze standardowego CMS'a. Dostarczamy surowe dane. Surowe – w sensie: bez informacji o tym jak te dane mają być zaprezentowane. Bo ta część jest po stronie aplikacji. To aplikacja decyduje (oczywiście, że programista!) jak zaprezentuje dostarczone dane. Albo aplikacje, bo nie jesteśmy ograniczeni tylko do jednej formy. Treści mogą być dostosowane do urządzenia, na którym działa aplikacja. Czy to ekran komputera, czy smartfona, czy wyświetlacz lodówki. Możemy mieć wiele różnych aplikacji, które mają dostęp do tych samych danych. Sam CMS ma zdecydowanie mniejsze zapotrzebowanie na zasoby maszyny, na której będzie pracował. Pięknie.


Żeby nie przedłużać, spośród dostępnych na rynku rozwiązań, szukałem przede wszystkim takich, które mają dostępne stabilne wersje, dokumentacje i umożliwiają instalację na własnej maszynie.


Początkowo wybrałem trzy, które mają już jakiej społeczności – co zawsze jest pomocne i przy okazji informuje jak „żywy” jest projekt.



  1. Strapi – Najbardziej zaawansowany, open-source`owy headless CMS pod Node.js. Dane przechowywać może w bazach SQL'owych jak MySQL, MariaDB, czy PostgreSQL, ale także w MongoDB.


  2. Cockpit – Już w PHP, przechowujący dane w bazie SQLight, lub MongoDB.


  3. Directus – PHP 7.1.x (na mikroframeworku Slim). Baza danych MySQL, MariaDB.


Wybór rozwiązania


„One side will make you grow taller, and the other side will make you grow shorter.”



Strapi


Prawie 10 tys gwiazdek na GitHubie, robi wrażenie. Podobnie prezentacja na oficjalnej stronie. Liczne feature’y wyglądają fantastycznie. To nic, że część ma status “coming soon”. Całość stawiana na Node.js, łatwo i przyjemnie. Tworzenie API jest proste, bezpieczne i szybkie - zachęcają slogany. Czas na testy i tutaj pierwszy zonk – Aktualna wersja 3.0-alpha. Naprawdę? Niestety, to wiąże się z dużą liczbą możliwych błędów, oraz: update’ów, problemów z kompatybilnością, słabą dokumentacją. Poprzednia wersja 1.6.4 (A gdzie v2.x?), niestety nie oferuje tych samych funkcjonalności, nie można też skorzystać z dokumentacji, bo wersje się różnią. No trudno, projekt cierpi na standardowe przypadłości wieku dziecięcego. Potrzeba jeszcze roku przynajmniej, aby można było liczyć na stabilność.



Cockpit


Połączenie PHP i MySQL (MariaDB), wydaje się takie naturalne, więc dlaczego miałbym łączyć się z MongoDB? Bo mogę. Oczywiście. Strukturę danych mam już określoną, nie mam dylematu z wyborem bazy danych. Możemy pracować na jednej, jak i na drugiej. Jedynie SQLight budzi wątpliwości. No, ale przecież nie jestem zmuszony, żeby korzystać. Dokumentacja jest. Do tego czytelna, niezbyt rozbudowana. Instalacja wymaga pobrania (z GitHub’a, lub z oficjalnej strony) pliku .zip, rozpakowania i wrzucenia do katalogu na serwerze. Możemy także zainstalować używając Docker’a. Skonfigurować dostęp do bazy danych i uruchomić skrypt wpisując /url/to/cockpit/install w naszej ulubionej przeglądarce. Co jeszcze nam oferuje? Generowanie tokenów, oczywiście minimalistyczny (ale nie prymitywny) UI, by tworzyć kolekcje (tak się nazywają nasze tabele, w których będziemy przechowywać dane), formularze, webhooks - jeśli użytkownik zechce zdefiniować własne callback`i, choćby po to, by na przykład wysyłać informacje na maila, po każdy utworzeniu nowej kolekcji. Mamy tutaj listę kilkunastu event’ów, które możemy wykorzystać. Jednego nie możemy. Cockpit oferuje własne API, umożliwiające utworzenie, odczytanie, zaktualizowanie czy usunięcie całej kolekcji, lub kilku wierszy. Niestety nie umożliwia w prosty sposób, rozszerzenia API, a przecież koledzy frontendowcy chcą proste URL. Nie, żeby te cockpit’owe były specjalnie skomplikowane, no ale.



Directus


Directus, to jakby dwie aplikacje: API – do komunikacji z bazą danych (CRUD) i aplikacją/aplikacjami, czy serwisami zewnętrznymi; APP – zawierającą UI, do łatwego tworzenia, wprowadzania, edytowania i usuwania danych. APP, napisana w całości w JavaScript, wykorzystuje API w tym samym celu, w którym i my możemy, tworząc własną aplikację. API powstał z wykorzystaniem PHP i nowoczesnego mikroframeworka Slim


System umożliwia tzw. mirroring bazy danych (możemy podłączyć Directusa, nawet do bazy WordPress’owej i zarządzać danymi z jego poziomu), albo utworzenia wszystkich niezbędnych tabel, łącznie z relacyjnymi, z poziomu panelu, do tego wykorzystanie RESTful API, oraz – i to chyba najważniejsza informacja – rozszerzenie istniejącego API, lub tworzenie własnych endpointów. I jeszcze parę innych funkcjonalności, ale o tym za chwilę. Dokumentacja jest czytelna i obejmuje zarówno obsługę CMS’a, jak i korzystanie z API. Co więcej, istnieje sporo tutoriali w sieci, jak korzystać z Directusa.


Chyba znalazłem, czego szukałem.



Problemy


“... round the neck of the bottle was a paper label, with the words ‘DRINK ME’ beautifully printed on it in large letters.”



Nowa, czy stara wersja?


Rozpocząłem testy i uczyłem się obsługi systemu. Ponieważ szybko udało się uzyskać oczekiwane efekty, mam tu na myśli zbudowanie odpowiednich tabel dla artykułów i obiektów, tabel relacyjnych, w tym umożliwiających tworzenie treści dla różnych języków (Tak, treści w naszej aplikacji dla klienta, powinny być dostępne w języku angielskim i hiszpańskim), itp. – postanowiłem przejść do drugiego etapu testów i zaprogramować własne API. W międzyczasie zespół Directusa triumfalnie ogłosił wydanie nowej wersji z numerkiem 7. Wraz z nową wersją udostępniona została nowa dokumentacja, nie do końca odpowiadające wersji, której używałem. Poprzednią dokumentację schowali na GitHubie w zakładce “Directus-6-Legacy”, szkoda tylko, że zapomnieli o tym poinformować.


Nowy Directus wprowadza szereg zmian. Przede wszystkim APP i API zostały rozdzielone. Teraz mogę używać jednej APP, by łączyć się z wieloma instancjami API, podłączonymi do różnych baz danych, a nawet umieszczony na oddzielnych maszynach i w innych domenach. Super! APP została w całości napisana w Vue.js (super super!), oczywiście możemy dodawać własne componenty i w ten sposób rozszerzać funkcjonalność, np. poprzez utworzenie własnych interface’ów. A to tylko jedna z możliwości. Super raz jeszcze! Tworzenie własnych endpointów to podobno bajka, versionless API, nie wspominając o bezpieczeństwie: autoryzacji, autentykacji, tokenizacji, czy Auth Providers z logowanie za pomocą np. konta z Twittera.


Niestety – wady wieku dziecięcego.



“... she found her head pressing against the ceiling, and had to stoop to save her neck from being broken.”



Własne API


Zostajemy więc przy stabilnej wersji 6.4.x. Niestety także tutaj dokumentacja (znalazłem pasująca do 6) nie jest wystarczająco jasna (może tylko dla mnie?), nie znalazłem też żadnych tutoriali pokazujących jak to zrobić dodatkowymi endpoint’ami. Ostatecznie, zmuszony byłem zmodyfikować plik api/api.php, dodając własną grupę rout’ów, z ograniczeniem wyłącznie do Requestów HTTP typu GET:


Kod: Zaznacz cały

$app->group("/go", function() use($app) {…}

URL zrozumiały, ale czy nie mógłby być prostszy?


Kod: Zaznacz cały

/nasza-domena/api/go/[nazwa-kolekcji]

Prawda, że czytelniej? Oczywiście dla aplikacji nie ma to znaczenia, ważne, żeby przesłany w odpowiedzi obiekt JSON był bez zbędnych informacji. A że przy okazji koledzy frontendowcy zadowoleni. Same plusy.


Nadal można korzystać (czasem trzeba) z parametrów typu (standardowe) lang, limit, offset, czy (nasze) home_country.



Instalacja, konfiguracja, praca, migracja


“However, I’ve got back to my right size: the next thing is, to get into that beautiful garden—how is that to be done, I wonder?”



Krótko jeszcze tylko o pracy z Directus’em. Instalacja jest banalnie prosta, jeśli tylko nasz serwer spełnia minimalne wymagania. Jeśli tak, wystarczy pobrać pliki odpowiedniej (u nas v6.4.x) wersji, rozpakować i uploadować do folderu docelowego na serwerze. Utworzyć bazę danych MySQL, oraz użytkownika z odpowiednimi uprawnieniami. Uruchomić skrypt instalacyjny wpisując w przeglądarce url do instancji Directusa. Jeśli uruchamiamy po raz pierwszy, należy wypełnić formularz danymi dotyczącymi naszego projektu, jak nazwa, ścieżka do projektu, adres admina itp, oraz dane do połączenia z bazą danych. Jeśli instalacja przebiegnie pomyślnie otrzymamy e-mail’a z potwierdzeniem.


Po instalacji możemy zmodyfikować plik konfiguracyjny api / config.php. Parametr ważny podczas pracy deweloperskiej DIRECTUS_ENV warto zmienić na development, aby otrzymywać informacje na temat ewentualnych błędów. Dobrze też zmiennej $host ustawić wartość na nazwę domeny, pod którą będzie dostępna instancja Directusa.


Przenoszenie całej aplikacji, z naszymi tabelami, także nie jest skomplikowane. Wystarczy przenieść pliki systemu do nowej lokalizacji, podłączyć bazę danych - plik api / config.php - zaimportować tabele ze starej bazy do nowej i voilà.



Troubleshooting


W specyficznych warunkach mogą wystąpić problemy przy migracji. Jednym ze sposób poradzenia sobie z nimi, jest przeprowadzenie procesu instalacji na nowej maszynie, a dopiero potem import tabel i plików z katalogu storage / uploads.


Ponieważ aktualnie wersja 6.4.x nie jest już rozwijana - dostępna jest tylko v.7.x - poprzednią wersję wraz z dokumentacją, może jeszcze przeglądać na oficjalnym koncie GitHub: (tutaj URL do dokumentacji)



---

* CRUD - akronim Create, Read, Update, Delete - Utwórz, Odczytaj, Zaktualizuj, Usuń - cztery podstawowe funkcje w aplikacjach korzystających z pamięci trwałej, które umożliwiają zarządzanie nią.
* UI - (ang. User Interface) - interfejs użytkownika, przestrzeń, w której następuje interakcja człowieka z maszyną.
* API - Interfejs programowania aplikacji, interfejs programistyczny aplikacji (ang. Application Programming Interface, API) – sposób, rozumiany jako ściśle określony zestaw reguł i ich opisów, w jaki programy komputerowe komunikują się między sobą.
* MySQL (MariaDB), SQLight, PostgreSQL - relacyjne bazy danych.
* MongoDB - otwarty, nierelacyjny system zarządzania bazą danych.


"Im więcej ćwiczę, tym więcej mam szczęścia"
"Jem kamienie. Mają smak zębów."

Awatar użytkownika
szopen
Pisarz pokoleń
Posty: 1114
Rejestracja: śr 25 kwie 2012, 13:10
OSTRZEŻENIA: 0
Płeć: Mężczyzna
Kontaktowanie:

Alicja w Krainie Czarów, czyli backend z Headless CMS

Postautor: szopen » sob 22 gru 2018, 14:11

P.Yonk pisze:Source of the post rzynajmniej raz stawało przed problemem, .... W naszej firmie często stajemy przed takim dylematem.

No powtórzenie.
P.Yonk pisze:Source of the post Jedynie SQLight budzi wątpliwości.

CHyba SQLite, albo pojawiło się coś nowego, o czym nie wiem...
P.Yonk pisze:Source of the post cockpit’owe
Ja rozumiem, slang, ale zarówno "eventy" jak i "cockpit" mają od dawien dawna spolszczenia. Kokpit, zdarzenia.

Natomiast największy problem mam z tym, czy to faktycznie jest publicystyka i dziennikarstwo. Wartość literacka nie jest tutaj zbyt duża :D




Wróć do „Dziennikarstwo i publicystyka”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 2 gości