1. Przeformułowanie pytania
Twój przykład sugeruje, że dane są odczytywane tylko po stronie Drupala, z synchronizacją tylko w jedną stronę. Myślę, że jest to najważniejszy czynnik, który należy wziąć pod uwagę, ponieważ w efekcie każde wdrożone rozwiązanie będzie wariantem zdalnego przechowywania, synchronizacji i lokalnego buforowania - nawet jeśli lokalne buforowanie zakończy się jako jednostki w bazie danych Drupal.
Zatem pytanie, zamiast być „pamięcią lokalną a pamięcią zdalną”, brzmi:
- Jeśli w ogóle buforujesz dane lokalnie;
- Jeśli buforujesz dane jako rzeczywiste jednostki i używasz kanałów (lub podobnych) do regularnej synchronizacji danych; LUB
- Jeśli używasz niestandardowego modułu, który zapewnia synchronizację i buforowanie.
Artykuł, który może Cię zainteresować, znajduje się w „ Zdalnych jednostkach w Drupal 7 ”.
2. Buforowanie danych
Ogólnie buforowanie danych jest dobrym pomysłem:
Jesteś chroniony przed przerwami w działaniu innych usług lub przekroczeniem limitu czasu połączenia;
Obecność danych w bazie danych Drupal przyspieszy operacje;
Obecność danych w bazie danych Drupal oznacza, że istnieje większe prawdopodobieństwo integracji z innymi modułami, takimi jak Widoki (choć nie jest to gwarantowane).
Jedyną zaletą braku buforowania danych jest to, że nigdy nie dostajesz przestarzałych danych, co w niektórych przypadkach jest lepsze - czasami lepiej nie wyświetlać żadnych danych niż nieaktualnych danych. Nie widzę tego w podanym przez ciebie przykładzie, dlatego skoncentruję się na odpowiedzi obejmującej lokalne buforowanie.
3. Podmioty lokalne + Synchronizacja
Jeśli wybierzesz opcję posiadania lokalnych podmiotów i samodzielnego ich synchronizowania, wrócimy do twoich oryginalnych pytań:
3.1 Węzły a podmioty niestandardowe
Definicja tego, czym dokładnie jest węzeł, jest dość otwarta. Strona dokumentacji w węzłach sugeruje, że węzły „publikują”, które są „przechowywane” w Twojej witrynie - żaden z nich nie dotyczy twoich danych;
Jako programista Drupal spodziewałbym się, że jeśli coś jest węzłem, powinienem być w stanie manipulować nim na samej stronie;
Jako użytkownik Drupala podobnie oczekiwałbym, że węzły można edytować;
Ten numer Drupala 8 https://drupal.org/node/2019031 sugeruje, że pojęcie „tylko do odczytu” to takie, które miałoby zastosowanie na poziomie jednostki, a nie na poziomie pakietu. Jeśli to kiedykolwiek zostanie wdrożone, skorzystasz z tego, idąc tą drogą.
Podsumowując: dane są tylko do odczytu i przechowywane zdalnie , bardziej sensowne jest użycie niestandardowego typu encji do reprezentowania danych.
3.2 Synchronizacja
W drugiej części dwoma głównymi modułami są, jak sugerujesz, kanały i migracja .
Różnica między Kanałami a Migracją polega na tym, że Kanały są budowane do regularnego importowania treści, podczas gdy Migracja jest przeznaczona do jednorazowego przenoszenia treści z jednego miejsca do drugiego. Migracja obsługuje aktualizację istniejących danych, jednak biorąc pod uwagę, że oba moduły są dobrze obsługiwane, sensowniej jest użyć modułu, który został zbudowany dla danego zadania - Kanały lepiej pasują.
Sam korzystałem z obu modułów (Kanały do synchronizacji, Migracja do migracji). Nie uważam, aby Kanały były bardziej niechlujne niż Migracja. Z mojego doświadczenia wynika, że migracja wymagała więcej niestandardowego kodu, chociaż migracja całych witryn jest bardziej złożona niż importowanie pojedynczych typów treści, więc trudno je porównać.
4. Niestandardowy moduł do zdalnego przechowywania, synchronizacji + buforowania
Istnieje wiele modułów, które mogą pomóc w tym zadaniu.
Wspomniałeś o module danych usług WWW , a inni wspomnieli o module danych . Inną opcją do rozważenia jest moduł API Remote Entity . Pamiętaj, że jedyną z nich, z którą mam doświadczenie, jest moduł danych.
Moduł danych usług WWW nie ma jeszcze wydania - co może wskazywać, że kod nie jest jeszcze stabilny, interfejs API może ulec zmianie i tak dalej. Nie obsługuje zapytań o pola encji (zgodnie ze stroną projektu), a szybkie przeglądanie repozytorium kodu nie pokazuje, że ma on obsługę widoków - więc nie można używać widoków do wyświetlania swoich bytów;
Z mojego doświadczenia wynika, że moduł danych jest bardziej zorientowany na programistów, którzy mają dane w tabeli i chcą je wystawiać na widoki. Uznałem, że korzystanie z wersji Drupal 6 jest dość frustrujące - choć od tego czasu mogło się to zmienić;
Moduł interfejsu API Remote Entity brzmi dość obiecująco - obsługuje pobieranie i buforowanie zdalnych jednostek oraz obsługę widoków. To jest tylko w wersji alfa - więc API może się jeszcze zmienić. Na pierwszy rzut oka wydaje się, że nie obsługuje on również Entity Field Query, a obsługuje tylko jeden typ zdalnej usługi, więc trzeba będzie wdrożyć własną.
Wniosek
Biorąc pod uwagę, że żaden ze zdalnych modułów pamięci nie obsługuje zapytań o pola encji, użycie rzeczywistych encji + kanałów jest rozwiązaniem, które zapewni najlepszą integrację z witryną Drupal.
Jeśli obsługa widoków jest wystarczająca i nie martwisz się potencjalną integracją z innymi modułami za pomocą zapytań Entity Field, skorzystaj z interfejsu Remote Entity API - możesz jednak zaimplementować własny interfejs zdalny.