Eu já vi várias estratégias para integrar estruturas de dados remotas no Drupal. As estratégias pareciam evoluir à medida que certos módulos se estabilizaram e os casos de uso foram tentados.
Imagine que temos uma estrutura de dados "Farmers Markets" que é representada por vários tipos de dados (market, market_hours, vender, stall, produzir) etc. que são expostos por meio de uma API REST. Os IDs para o serviço externo precisariam se relacionar no Drupal, ou seja, ao carregar um "mercado", gostaríamos de pegar dados do 'market_hours' e 'stall'. Qual seria a melhor maneira de representar isso como conteúdo somente leitura no Drupal, sincronizado regularmente?
Estou tentando avaliar isso com os seguintes critérios:
Estruturas de dados no Drupal:
Nós x entidades personalizadas
Vários cenários envolvendo serviços da web que eu já vi usarem entidades personalizadas. Simplifica as operações CRUD. No entanto, esses itens teriam "conteúdo", pois seriam exibidos publicamente.
Armazenamento (Local x Remoto):
Eu já vi alguns exemplos em que os serviços são carregados como entidades remotas, para as quais este módulo cria uma biblioteca: https://drupal.org/project/wsdata . Isso parece mais atraente, mas não vi muitos casos de uso. Também existem exemplos de código personalizado: https://drupal.org/sandbox/fago/1493180
Sincronizando dados:
Feeds vs Migrar vs Guzzle vs 'Cliente de serviços da Web' vs 'Dados de serviços da Web'
Há uma série de opções. Os feeds agora suportam entidades. Migrar parece muito mais limpo que feeds, especialmente para cenários personalizados. Também vi pessoas usando um cliente guzzle para sincronizar com serviços remotos: http://drupalcode.org/project/ckan.git/blob/refs/heads/ckan_dgu_7.x-1.x:/ckan.drush. inc # l273 . Também notei que o módulo do Cliente WS https://drupal.org/project/wsclient fornece uma opção que foi criada especificamente como um cliente de descanso. Os dados de serviços da Web são carregados diretamente de um serviço e os armazenam em cache localmente.
Obrigado por qualquer pensamento.
Respostas:
1. Reformulando a pergunta
Seu exemplo sugere que os dados são somente leitura no lado do Drupal, apenas com sincronização unidirecional. Acho que esse é o fator mais importante a ser considerado aqui, porque, na verdade, qualquer solução que você implemente será uma variante de armazenamento remoto, sincronização e cache local - mesmo que o cache local acabe sendo entidades no banco de dados Drupal.
Portanto, a questão, em vez de ser "armazenamento local versus armazenamento remoto", será:
Um artigo em que você pode estar interessado está em " Entidades remotas no Drupal 7 ".
2. Armazenando em cache os dados
Em geral, armazenar em cache os dados é uma boa ideia:
Você está protegido contra interrupções nos outros serviços ou tempos limite na conexão;
Ter seus dados presentes no banco de dados do Drupal acelerará as operações;
A presença de seus dados no banco de dados Drupal significa que é mais provável que você obtenha integração com outros módulos, como Views (embora isso não seja garantido).
A única vantagem de não armazenar em cache os dados é que você nunca obtém dados obsoletos, o que em alguns casos é preferível - às vezes é preferível não exibir dados em vez de dados obsoletos. Não vejo isso como um benefício no exemplo que você deu, portanto, focarei esta resposta em uma solução que envolve o cache local.
3. Entidades locais + Sincronização
Se você optar por ter entidades locais e sincronizá-las você mesmo, voltaremos às suas perguntas originais:
Você deve usar nós ou entidades personalizadas;
Qual módulo é melhor para sincronizar.
3.1 Nós x entidades personalizadas
A definição do que exatamente é um nó é bastante aberta. A página de documentação nos nós sugere que os nós estão "postando" e "armazenados" no seu site - nenhum dos quais se aplica aos seus dados;
Como desenvolvedor do Drupal, eu esperaria que, se algo fosse um nó, eu pudesse manipulá-lo no próprio site;
Como usuário do Drupal, eu também esperaria que os nós pudessem ser editados;
Esta edição do Drupal 8, https://drupal.org/node/2019031, sugere que o conceito de "somente leitura" é aquele que se aplicaria no nível da entidade e não no nível do pacote. Se isso for implementado, você se beneficiará disso por seguir esse caminho.
Para resumir: seus dados sendo somente leitura e armazenados remotamente , faz mais sentido usar um tipo de entidade personalizado para representar seus dados.
3.2 Sincronizando
Para a segunda parte, os dois módulos principais para isso são, como você sugere, Feeds e Migração .
A diferença entre Feeds e Migrate é que os Feeds são criados para a importação regular de conteúdo, enquanto o Migrate é criado para a transferência única de conteúdo de um lugar para outro. O Migrate suporta a atualização de dados existentes, no entanto, como os dois módulos são bem suportados, faz mais sentido usar o módulo que foi criado para a tarefa em questão - os feeds são uma correspondência melhor.
Tendo usado os dois módulos eu mesmo (Feeds para sincronização, Migrando para migração), não acho que os Feeds sejam mais confusos do que Migrar. Migrar exigiu mais código personalizado em minha experiência, embora a migração de sites inteiros seja mais complexa do que a importação de tipos de conteúdo únicos, por isso é difícil comparar.
4. Módulo personalizado para armazenamento remoto, sincronização + cache
Existem vários módulos por aí que podem ajudar nessa tarefa.
Você mencionou o módulo Dados dos Serviços da Web e outros mencionaram o módulo Dados . Outra opção a considerar é o módulo da API de entidade remota . Observe que o único daqueles com quem tenho experiência é o módulo Dados.
O módulo Dados de Serviços da Web ainda não possui uma liberação - o que pode indicar que o código ainda não está estável, a API pode mudar e assim por diante. Ele não suporta consultas de campo de entidade (de acordo com a página do projeto) e uma rápida navegação no repositório de códigos não mostra evidências de que ele tenha suporte a Views - portanto, você não poderá usar o Views para exibir suas entidades;
O módulo Dados é mais orientado, na minha experiência, para não desenvolvedores que possuem dados em uma tabela e desejam expô-los a visualizações. Eu achei a versão do Drupal 6 bastante frustrante de usar - embora isso possa ter mudado desde então;
O módulo da API de entidade remota parece bastante promissor - suporta a busca e o cache de entidades remotas e possui suporte a Views. É apenas na versão alfa - portanto, a API ainda pode mudar. À primeira vista, também não parece ter o suporte a Consulta de Campo de Entidade, e suporta apenas um tipo de serviço remoto, portanto você precisaria implementar o seu próprio.
Conclusão
Como nenhum dos módulos de armazenamento remoto suporta consultas de campo de entidade, o uso de entidades + feeds reais é a solução que fornecerá a melhor integração com o site Drupal.
Se o suporte a Views for suficiente e você não estiver preocupado com a possível integração com outros módulos por meio de consultas de campo de entidade, o uso da API de entidade remota pode ser o caminho a seguir - você precisará implementar sua própria interface remota.
fonte
Se você precisar de visualizações, regras, tokens, ganchos de cruds, api de pesquisa e definitivamente integração forte do sistema, na minha opinião, eles não podem ser considerados nós, mas devem ser entidades personalizadas com sua própria idiossincrasia armazenando no banco de dados o "ID da entidade" e o relação "id externo" e com as chamadas de recuperação de informações encapsuladas nas "propriedades da entidade". Finalmente, qualquer que seja a ferramenta que você escolher para sincronizar dados, eu a processaria com as filas cron.
Se você apenas precisar recuperar e expor dados pontualmente, acho que uma opção melhor seria criar uma classe de interface para recuperar dados externos e implementar essa interface com uma classe que recupera as informações da estrutura "Mercados de agricultores".
Saudações
fonte
Existe a API Field Storage , que permite back-ends de armazenamento conectáveis que não sejam o mecanismo de banco de dados padrão.
fonte