1. Reformulando la pregunta
Su ejemplo sugiere que los datos se leen solo en el lado de Drupal, solo con sincronización unidireccional. Creo que este es el factor más importante a considerar aquí, porque en efecto, cualquier solución que implemente será una variante de almacenamiento remoto, sincronización y almacenamiento en caché local, incluso si el almacenamiento en caché local termina siendo entidades en la base de datos de Drupal.
Entonces, la pregunta, en lugar de ser "almacenamiento local versus almacenamiento remoto" será:
- ¿Debería almacenar en caché los datos localmente?
- Debe almacenar en caché los datos como entidades reales y utilizar Feeds (o similares) para sincronizar los datos regularmente; O
- Debería usar algún módulo personalizado que proporcione la sincronización y el almacenamiento en caché.
Un artículo que puede interesarle está en " Entidades remotas en Drupal 7 ".
2. Almacenamiento en caché de los datos
En general, el almacenamiento en caché de los datos es una buena idea:
Usted está protegido contra interrupciones de los otros servicios o tiempos de espera en la conexión;
Tener sus datos presentes en su base de datos Drupal acelerará las operaciones;
Tener sus datos presentes en su base de datos de Drupal significará que es más probable que obtenga integración con otros módulos, como Vistas (aunque esto no está garantizado).
La única ventaja de no almacenar en caché los datos es que nunca se obtienen datos obsoletos, lo que en algunos casos es preferible, a veces es preferible no mostrar datos en lugar de datos obsoletos. No veo esto como un beneficio en el ejemplo que ha dado, por lo que enfocaré esta respuesta en una solución que implique el almacenamiento en caché local.
3. Entidades locales + sincronización
Si opta por tener entidades locales y sincronizarlas usted mismo, volveremos a sus preguntas originales:
3.1 Nodos vs entidades personalizadas
La definición de qué es exactamente un nodo es bastante abierta. La página de documentación sobre los nodos sugiere que los nodos están "publicando" que están "almacenados" en su sitio, ninguno de los cuales se aplica a sus datos;
Como desarrollador de Drupal, esperaría que si algo es un nodo, debería poder manipularlo en el sitio mismo;
Como usuario de Drupal, esperaría de manera similar que los nodos se puedan editar;
Esta edición de Drupal 8 https://drupal.org/node/2019031 sugiere que el concepto de "solo lectura" se aplicaría a nivel de entidad, en lugar de a nivel de paquete. Si esto alguna vez se implementa, se beneficiaría al seguir esta ruta.
Para resumir: sus datos se leen y almacenan de forma remota , tiene más sentido usar un tipo de entidad personalizada para representar sus datos.
3.2 Sincronización
Para la segunda parte, los dos módulos principales para esto son, como sugiere, Feeds y Migrate .
La diferencia entre Feeds y Migrate es que Feeds está diseñado para la importación regular de contenido, mientras que Migrate está diseñado para portar contenido de una sola vez de un lugar a otro. Migrate admite la actualización de los datos existentes, sin embargo, dado que ambos módulos están bien soportados, tiene más sentido usar el módulo que fue construido para la tarea en cuestión: Feeds es una mejor opción.
Después de haber utilizado ambos módulos (Feeds para sincronizar, Migrar para migrar) no creo que los Feeds sean más desordenados que Migrate. Migrar ha requerido más código personalizado en mi experiencia, aunque migrar sitios enteros es más complejo que importar tipos de contenido individuales, por lo que es difícil de comparar.
4. Módulo personalizado para almacenamiento remoto, sincronización + almacenamiento en caché
Existen varios módulos que pueden ayudar con esta tarea.
Usted mencionó el módulo de datos de servicios web , y otros han mencionado el módulo de datos . Otra opción a considerar es el módulo API de entidad remota . Tenga en cuenta que el único con el que tengo experiencia es el módulo de datos.
El módulo de datos de servicios web aún no tiene una versión, lo que puede indicar que el código aún no es estable, la API podría cambiar, etc. No admite consultas de campo de entidad (de acuerdo con su página de proyecto), y una exploración rápida del repositorio de código no muestra evidencia de que tenga soporte para vistas, por lo que no podrá usar vistas para mostrar sus entidades;
El módulo de datos está más orientado, en mi experiencia, hacia los no desarrolladores que tienen datos en una tabla y desean exponerlos a las vistas. He encontrado que la versión Drupal 6 es bastante frustrante de usar, aunque eso podría haber cambiado desde entonces;
El módulo API de entidad remota suena bastante prometedor: admite la recuperación y el almacenamiento en caché de entidades remotas, y tiene soporte para vistas. Solo está disponible en versión alfa, por lo que la API aún puede cambiar. A primera vista, tampoco parece tener compatibilidad con Entity Field Query, y solo admite un tipo de servicio remoto, por lo que tendría que implementar el suyo.
Conclusión
Dado que ninguno de los módulos de almacenamiento remoto admite consultas de campo de entidad, el uso de entidades reales + feeds es la solución que le brindará la mejor integración con su sitio Drupal.
Si el soporte de Vistas es suficiente y no le preocupa la posible integración con otros módulos a través de consultas de campo de entidad, entonces el uso de la API de entidad remota podría ser el camino a seguir; sin embargo, necesitaría implementar su propia interfaz remota.