Multisite, Domain Access czy headless – jak obsłużyć wiele domen w Drupalu?

Obsługa wielu domen w jednym systemie CMS to wyzwanie, z którym mierzy się wiele organizacji. Wybór odpowiedniej architektury na początku projektu pozwala zaoszczędzić czas i pieniądze. Drupal oferuje trzy sprawdzone podejścia: multisite, Domain Access oraz headless CMS. W tym artykule porównam ich zalety i wady, pokażę konkretne przykłady wdrożeń i podpowiem, które rozwiązanie najlepiej sprawdzi się w różnych scenariuszach biznesowych. Zapraszam do przeczytania wpisu lub obejrzenia odcinka z cyklu Nowoczesny Drupal.

W tym artykule:

• Dlaczego warto rozważyć obsługę wielu domen w jednym systemie?
• Trzy podejścia do obsługi wielu domen w Drupalu
• Multisite – jedna baza kodu, osobne bazy danych
• Domain Access – jedna baza kodu i jedna baza danych
• Headless Drupal – backend API z niezależnymi frontendami
• Porównanie trzech podejść – multisite, Domain Access i headless
• Kiedy wybrać multisite, Domain Access, a kiedy headless?
• Jak obsłużyć wiele domen w Drupalu - podsumowanie

Dlaczego warto rozważyć obsługę wielu domen w jednym systemie?

Zanim przejdę do szczegółów poszczególnych architektur, warto zastanowić się, dlaczego w ogóle warto rozważać obsługę wielu domen w jednym systemie CMS. Odpowiedź sprowadza się do kilku kluczowych korzyści, które bezpośrednio przekładają się na czas i budżet zespołu.

Po pierwsze, zyskujesz centralne zarządzanie kodem i modułami. Aktualizujesz wszystko jeden raz, a zmiany stają się dostępne od razu dla wszystkich stron. Po drugie, oszczędzasz zasoby serwerowe – jedna instancja Drupala jest lżejsza i tańsza w utrzymaniu niż kilka oddzielnych instalacji. Łatwiej zarządzasz też użytkownikami i uprawnieniami, zyskujesz możliwość współdzielenia treści, a utrzymanie i rozwój systemu stają się znacznie bardziej efektywne.

Przykładowo pojawia się nowa wersja modułu, na przykład modułu AI w Drupalu z nowymi funkcjonalnościami, czy jakaś poprawka bezpieczeństwa. Wdrażasz to raz i nie musisz aktualizować każdej strony osobno.

Trzy podejścia do obsługi wielu domen w Drupalu

Drupal oferuje trzy główne podejścia do obsługi wielu domen. Pierwszym jest multisite, w którym używamy jednej bazy kodu (jednego codebase’a), ale każda domena ma swoją osobną bazę danych.

Drugie podejście to Domain Access – dodatkowy moduł, który pozwala na obsługę wielu domen z jedną bazą kodu i jedną wspólną bazą danych.

Trzecie podejście to headless CMS, gdzie Drupal działa jako backend, dostarcza treści przez API, a każda domena może mieć swój własny, niezależny frontend. W przypadku headlessa bazy danych mogą być osobne lub wspólne, zależnie od decyzji podjętej na etapie planowania systemu.

Każde z tych podejść ma swoje mocne i słabe strony. Poniżej omawiam je szczegółowo, podając przykłady firm, które z nich korzystają.

Multisite – jedna baza kodu, osobne bazy danych

Drupal Multisite to funkcjonalność wbudowana w rdzeń systemu, więc nie wymaga instalacji żadnych dodatkowych modułów. W praktyce polega to na tym, że mamy jeden folder z kodem Drupala, ale dla każdej strony tworzymy osobną bazę danych i osobny folder w katalogu sites.

Każda strona posiada własne ustawienia, może korzystać ze wspólnych modułów lub mieć zainstalowane własne, a motywy graficzne (skórki) mogą być wspólne dla wszystkich domen lub też przypisane do poszczególnych stron. To samo dotyczy plików mediów i plików do pobrania – każda instancja posiada własny katalog.

Przykład: strona Droptica.com

Droptica używa architektury multisite do obsługi czterech domen: droptica.com, droptica.pl, kariera.droptica.pl oraz szkolenia.droptica.pl. Wszystkie cztery domeny działają na jednym codebase, posiadają cztery osobne bazy danych i są hostowane na jednym projekcie na platformie Upsun (wcześniej Platform.sh).

Treści na poszczególnych domenach są odseparowane, ale funkcjonalności – takie jak dodawanie nowych modułów czy nowych paragrafów (Droptica używa systemu Droopler z modułem Paragraphs do budowy treści – są współdzielone. Kiedy pojawia się nowy paragraf, jest od razu dostępny na wszystkich domenach.

Aktualizacja bezpieczeństwa także nie wymaga aktualizowania czterech stron osobno. Wystarczy przeprowadzić ją jednorazowo, co przekłada się na wyraźną oszczędność czasu przy utrzymaniu tych serwisów.

Zalety multisite

Do głównych zalet multisite należy łatwiejsza aktualizacja – zarówno rdzenia Drupala, jak i modułów. Wszystkie zmiany wdrażasz jednocześnie dla każdej domeny. Zyskujesz oszczędność miejsca na dysku, ponieważ Drupal, moduły i cały katalog vendor (który potrafi zajmować sporo miejsca) istnieją na serwerze tylko raz, niezależnie od liczby domen. Każda strona może mieć niezależną konfigurację, a pełna izolacja baz danych zapewnia separację treści między domenami.

Wady multisite

Wśród wad warto wymienić trudniejsze zarządzanie współdzieleniem treści. Ponieważ każda domena ma osobną bazę danych, treści nie są automatycznie dostępne na innych stronach. Istnieje wprawdzie opcja współdzielenia niektórych tabel bazy danych poprzez konfigurację w pliku settings.php, co pozwala dzielić wybrane dane między instancjami w multisite, ale z taką konfiguracją trzeba bardzo uważać – jest to podejście ryzykowne i raczej odradzane.

Kolejną wadą jest wymóg, aby wszystkie strony korzystały z tej samej wersji Drupala i modułów – nie da się zaktualizować jednej domeny bez aktualizacji pozostałych. Problemy z jedną stroną mogą wpłynąć na działanie pozostałych domen. Konfiguracja serwera dla multisite jest też nieco bardziej wymagająca niż w przypadku pojedynczej instalacji Drupala.

Przeczytaj również: Jak działa multisite w Drupalu

Domain Access – jedna baza kodu i jedna baza danych

Domain Access (aktualnie nazywany po prostu modułem Domain) to moduł dla Drupala, który pozwala na obsługę wielu domen w ramach jednej instalacji, współdzieląc zarówno kod, jak i bazę danych. To kluczowa różnica w porównaniu z multisite, gdzie każda domena miała osobną bazę danych.

Moduł dodaje specjalne pole do każdego typu treści, dzięki któremu przy tworzeniu dowolnej treści zawsze widzisz dodatkowe pole na formularzu, gdzie oznaczasz, do której domeny dana treść jest przypisana. W zależności od ustawień może to być przypisanie do jednej domeny lub do wielu domen jednocześnie.

Zastosowania Domain Access

To rozwiązanie jest szczególnie popularne w branży farmaceutycznej oraz wśród producentów fizycznych produktów, gdzie firmy często tworzą osobne strony dla każdego produktu. Duża część treści – jak informacje o firmie, dane kontaktowe czy regulaminy – jest współdzielona między domenami. Domain Access umożliwia zarządzanie wszystkimi stronami z jednego miejsca, przy jednoczesnym dostosowaniu wyglądu do konkretnego produktu na danej domenie.

Zalety Domain Access

Największą zaletą jest współdzielenie treści między domenami. Tworzysz treść raz i możesz opublikować ją na wielu domenach jednocześnie. System oferuje wspólną bazę użytkowników, ról i uprawnień, co upraszcza zarządzanie dostępem. Elastyczne uprawnienia pozwalają określić, kto ma dostęp do jakich treści i na której domenie – możesz mieć redaktorów globalnych albo redaktorów przypisanych wyłącznie do konkretnej domeny. Na różnych domenach możesz też stosować różne motywy graficzne, zachowując pod spodem spójność danych w systemie CMS.

Wady Domain Access

Wspólna baza danych oznacza mniejszą izolację danych. Problemy mogą wpływać jednocześnie na wszystkie domeny. Konfiguracja systemu jest bardziej złożona, a utrzymanie przy dużej liczbie domen (dziesiątkach czy setkach) może stanowić wyzwanie.

Szczególną uwagę należy zwrócić na sytuację, w której chcesz używać w systemie innych modułów zarządzających uprawnieniami do treści, które wykorzystują wbudowany w rdzeń Drupala mechanizm o nazwie Node Access Grants. Moduł Domain Access korzysta właśnie z tej funkcjonalności. Jeżeli w systemie działa kilka modułów podpinających się pod to, mogą pojawić się konflikty. W efekcie treści mogą mieć zbyt ograniczony lub zbyt szeroki dostęp. Czasami konieczne staje się napisanie dodatkowego modułu, który połączy ustawienia z wielu modułów korzystających z Node Access.

Przy Domain Access warto też starannie zaplanować strukturę treści i taksonomię, aby system pozostał przejrzysty i wygodny w codziennym użytkowaniu.

Headless Drupal – backend API z niezależnymi frontendami

W modelu headless Drupal działa wyłącznie jako backend – dostarcza treści, podczas gdy frontend jest stworzony przy użyciu technologii JavaScript, takich jak React, Angular czy Vue. Komunikacja odbywa się przez API, najczęściej JSON API lub GraphQL, w zależności od zaplanowanej architektury backendu.

Przykład: strony Polskiego Związku Piłki Nożnej

Bardzo dobrym przykładem wykorzystania architektury headless jest Polski Związek Piłki Nożnej (PZPN). PZPN używa jednego centralnego systemu Drupala, który służy jako źródło treści dla wielu serwisów internetowych. Takie podejście pozwala na stworzenie zoptymalizowanych frontendów dla różnych odbiorców i różnych domen, przy zachowaniu spójności treści i struktury danych w całym ekosystemie serwisów internetowych PZPN-u.

Zalety headless

Headless daje pełną elastyczność w tworzeniu frontendów dla różnych domen. Każdy serwis może mieć zupełnie inny wygląd i odmienną funkcjonalność. Możesz zoptymalizować każdy frontend pod kątem SEO i wydajności w indywidualny sposób. Integracja z aplikacjami mobilnymi staje się naturalna – skoro API już istnieje, aplikacja mobilna podłącza się pod te same endpointy co strony internetowe. Zespoły frontendowe i backendowe mogą pracować niezależnie, co często przyspiesza tempo rozwoju całego projektu.

Wady headless

Największą wadą jest złożoność techniczna wynikająca z połączenia kilku technologii. Na backendzie masz Drupala, na froncie różne frameworki JavaScript, a czasem nawet różne frameworki na różnych domenach. Wymagania dotyczące umiejętności zespołu są wyższe – potrzebni są specjaliści zarówno od Drupala, jak i od technologii frontendowych.

Konieczne jest zarządzanie wieloma repozytoriami kodu (wieloma codebase’ami), co zwiększa koszty utrzymania. Przy wdrożeniach trzeba zachować szczególną ostrożność. Zmiany po stronie frontendu często muszą być zsynchronizowane ze zmianami po stronie backendu, a wdrożenia nowych wersji obu aplikacji trzeba przeprowadzać w odpowiedniej kolejności, pamiętając o zachowaniu kompatybilności.

Porównanie trzech podejść – multisite, Domain Access i headless

Zestawienie najważniejszych parametrów pomaga zorientować się, które podejście sprawdzi się w konkretnej sytuacji. Poniżej porównam multisite, Domain Access i headless pod kątem pięciu kluczowych kryteriów.

Łatwość implementacji

Multisite jest najprostszy do uruchomienia, ponieważ jest wbudowany w rdzeń Drupala. Domain Access wymaga nieco większego nakładu pracy – instalacji i konfiguracji dodatkowego modułu, zaplanowania struktury treści i uprawnień. Headless wymaga największych nakładów pracy i najszerszej wiedzy technicznej, gdyż łączy kilka różnych technologii.

Współdzielenie treści

Domain Access zdecydowanie prowadzi w tej kategorii, ponieważ operuje na jednej bazie danych – treści tworzysz raz i publikujesz na wielu domenach. Multisite ma tutaj najmniejsze możliwości ze względu na osobne bazy danych. W przypadku headlessa ocena zależy od wybranej architektury – możesz mieć jedną wspólną bazę danych lub wiele oddzielnych, zależnie od potrzeb projektu.

Izolacja danych

Sytuacja jest odwrotna niż przy współdzieleniu treści. Multisite zapewnia najlepszą separację danych, bo każda domena ma własną bazę. Domain Access oferuje najmniejszą izolację, a headless – podobnie jak przy współdzieleniu – zależy od wybranej architektury. Izolacja danych może być istotna ze względów bezpieczeństwa w niektórych branżach i projektach.

Elastyczność frontendu

Headless jest tutaj bezkonkurencyjny i oferuje właściwie niemal nieograniczone możliwości.

Łatwość utrzymania

Najwyższą łatwość utrzymania zapewnia Domain Access, bo mamy jeden codebase i jedną bazę danych, a wszystko jest zarządzane centralnie.

Kiedy wybrać Multisite, Domain Access, a kiedy Headless?

Wybór odpowiedniej architektury powinien wynikać z analizy konkretnych potrzeb Twojej organizacji. Poniżej przedstawiam scenariusze, w których każde z trzech podejść sprawdza się najlepiej.

Kiedy wybrać multisite?

Multisite będzie najlepszym wyborem, gdy potrzebujesz niezależnych stron o podobnej strukturze, ale z różną zawartością. Dobrym przykładem jest strona firmowa Droptica – system Droopler, gdzie struktura danych jest taka sama na wszystkich domenach, ale treści są różne i odseparowane. To rozwiązanie sprawdzi się, gdy zależy Ci na łatwych aktualizacjach wszystkich stron jednocześnie, ale nie potrzebujesz zaawansowanego współdzielenia treści między domenami.

Kiedy wybrać Domain Access?

Domain Access to odpowiedni wybór, gdy potrzebujesz intensywnego współdzielenia treści między domenami i chcesz mieć wspólną bazę użytkowników. Przy dużej liczbie podobnych stron Domain Access może okazać się najbardziej efektywnym podejściem.

Kiedy wybrać headless?

Headless sprawdzi się, gdy potrzebujesz bardzo różnych interfejsów i frontendów dla poszczególnych domen lub planujesz aplikacje mobilne albo inne kanały dystrybucji treści. Warto rozważyć to podejście, gdy Twój zespół posiada doświadczenie w technologiach frontendowych i chcesz wykorzystać te umiejętności do budowy zoptymalizowanych interfejsów.

Czynniki wpływające na decyzję

Warto spojrzeć na kilka dodatkowych czynników, które mogą wpłynąć na wybór architektury. Budżet i dostępne zasoby to jeden z nich – headless wymaga największych nakładów zarówno czasowych, jak i kompetencyjnych. Zyskujesz elastyczność frontendów, ale poświęcasz więcej czasu na stworzenie i utrzymanie systemu, bo masz kilka codebase’ów i kilka technologii do utrzymania.

Liczba i różnorodność domen to kolejny czynnik. Potrzeby współdzielenia treści, plany rozwojowe na przyszłość oraz wymagania wydajnościowe to elementy, które również należy uwzględnić przy podejmowaniu decyzji.

Warto dokładnie przeanalizować te czynniki indywidualnie, ponieważ późniejsza zmiana podejścia może być kosztowna i czasochłonna.

Jak obsłużyć wiele domen w Drupalu - podsumowanie

Każde z omówionych podejść ma swoje zalety i wady, a wybór zależy od konkretnych potrzeb Twojej firmy lub organizacji. Multisite oferuje prostotę i separację danych. Domain Access świetnie sprawdza się ze współdzieleniem treści. Headless zapewnia ogromną elastyczność frontendu.

W praktyce często spotykamy się z rozwiązaniami hybrydowymi, czyli łączeniem różnych podejść. Na przykład można używać Domain Access dla głównej grupy powiązanych stron korporacyjnych, a multisite dla bardziej niezależnych serwisów. Innym wariantem jest korzystanie z Domain Access dla głównych stron firmowych, a headlessa dla stron produktowych – prostych serwisów składających się z kilku podstron, gdzie treść dostarczana jest z centralnego systemu, a frontend budowany osobno.

Warto starannie zaplanować architekturę i dobrze zastanowić się nad wyborem podejścia. Nawet jeśli początkowa decyzja nie okaże się optymalna, później można ją zmienić – przejść z jednego podejścia na drugie albo stworzyć hybrydę. Jeśli jednak przemyślisz architekturę na samym początku, oszczędzisz czas i pieniądze.

Potrzebujesz wsparcia w projektowaniu architektury wielodomenowej w swoim przypadku? Nasza agencja Drupala pomoże Ci wybrać i wdrożyć rozwiązanie, które będzie najlepiej odpowiadało celom Twojego projektu.

Ten artykuł powstał na bazie materiału wideo. Zapraszamy do subskrybowania kanału Nowoczesny Drupal, gdzie regularnie publikujemy nowe filmy. Nasi eksperci prezentują rozwiązania i gotowe narzędzia, które pomogą Ci wykorzystać pełen potencjał Drupala.