Apollo-link-rest: Redirecionamentos de cache de descanso aninhado de consulta

Você pode criar um exemplo mínimo demonstrando o problema? AFAIK, o cache estaria antes do link restante na cadeia, portanto, ele deve ser armazenado da mesma forma que uma consulta regular.

Vou tentar publicar um exemplo o mais rápido possível. O cache realmente funciona, mas apenas no nível superior (por exemplo, para livros no meu exemplo), mas não em objetos anotados restantes aninhados

@NikoSperat Temos um PR procurando melhorar o suporte de @export( , então, se você pudesse contribuir com um teste de unidade, poderíamos validar se seu caso de uso foi coberto!

Veja aqui: https://github.com/apollographql/apollo-link-rest/pull/204

Eu não acho que meu PR irá abordar isso, ele apenas lida com a correção de @export variáveis. Parece que esse problema está mais relacionado a fazer uma verificação de cache antes de buscar uma solicitação @rest aninhada.

Parece que puxar esses dados do cache exigiria alguma intervenção do usuário para mim. Apollo não saberá necessariamente que o usuário em /authors/{exportVariables.id} será um Author com id=id . Como desenvolvedor, você está ciente disso, portanto, pode fornecer essa inteligência, mas parece difícil para a biblioteca antecipar quaisquer casos de uso para fornecer comportamentos padrão.

Talvez uma função de busca personalizada que se integre com o cache alcance o que você deseja.

Suponho que um parâmetro id poderia ser adicionado à diretiva @rest que, combinada com type , poderia fazer uma verificação de cache para você. Mas também me preocuparia com comportamentos ocultos como esse; alguns usuários (inclusive eu) não esperariam que @rest fosse armazenado em cache por padrão e prefeririam que uma busca aninhada atualizasse o recurso, mesmo que estivesse em cache. Não necessariamente um recurso ruim a ser adicionado, se for configurável e o caso de uso estiver claramente definido.

É como explicado @ a-type. Agora vejo os problemas aqui, por que seria difícil responder com dados em cache.
Na verdade, escrevi um pequeno PoC com uma função de busca personalizada e pesquisa direta de cache. Não foi muito difícil, mas no final isso apenas adicionará mais algum código personalizado que é difícil de manter. - Isso é o que tentamos evitar e por que estamos usando apollo e link-rest em vez de escrever nossas próprias bibliotecas de busca em primeiro lugar.
Dar a possibilidade de fornecer uma função de redirecionamento personalizada para objetos de descanso aninhados e resolvê-los antecipadamente seria provavelmente uma boa solução

Eu acho que há potencial em adicionar parâmetros id e cache a @rest pessoalmente. O usuário poderia basicamente dizer ao ALR "Meu propósito ao chamar esta solicitação REST é recuperar o Post com id =" foo "; se você já o tiver no cache, pule a solicitação e retorne-a diretamente". O ALR poderia então facilmente executar uma consulta no cache para esse recurso antes de fazer a solicitação.

No entanto, isso adicionaria um recurso bastante significativo à biblioteca, então eu deixaria para os mantenedores decidir se vale a pena dar uma olhada.

Existe uma maneira de conseguir isso com o código personalizado enquanto isso? Estou tentando fazer exatamente isso e qualquer sugestão seria muito apreciada

@typon Em teoria, você poderia usar readFragment dentro de uma função fetch usando alguma lógica que você escreve para determinar a intenção da solicitação pelo URL fornecido. Se readFragment retornar dados para o recurso, você pode reembalá-los para se parecer com uma resposta de busca normal e retorná-los em vez de fazer a solicitação. Mas tenho certeza de que haveria outras armadilhas para contornar ao escrever isso.

Não tenho nada a acrescentar a este tópico, conforme mostrado nos comentários do a-type, seria uma mudança bastante significativa, e eu não sei exatamente como fazer esse recurso funcionar de maneira globalmente eficiente e fácil de manter caminho. É possível que @typon @NikoSperat considere apollo-link-state (agora diretamente uma parte do cliente Apollo) como uma forma de obter a API necessária.

Você definitivamente está olhando para o interior do Apollo, no entanto!

Se fosse eu, dividiria isso em duas consultas que realizam o trabalho sequencialmente.

@fbartho é o mesmo para consultas @rest não aninhadas? Por exemplo, no exemplo abaixo, warehouses será resolvido do cache quando Book query for chamada após Books query? Eu tinha certeza que sim, mas não é. Estou esquecendo de algo?

query Books
  books @rest(type: "[Book]", path: "/books") {
    id
    sku
  }
  warehouses @rest(type: "[Warehouse]", path: "/warehouses") {
    id
    name
  }
}

query Book
  book @rest(type: "Book", path: "/books/123") {
    id
    sku
  }
  warehouses @rest(type: "[Warehouse]", path: "/warehouses") {
    id
    name
  }
}

O controle detalhado do armazenamento em cache é mais uma questão para o ApolloClient. (E algumas coisas podem não ser fáceis de fazer com apollo-links)

Além disso, tenho quase certeza de que com o GraphQL puro ele também não resolveria esses dois tipos de consultas diretamente do cache e acertaria seu back-end duas vezes lá também.

O GraphQL não entende realmente que a consulta book-by-id é exatamente equivalente a find-entry-in-books-list-query-that-match-my-id. Isso faz sentido @edgars-sirokovs?