Muitas chamadas da API REST em uma página?

8

Um aplicativo da Web projetado com componentes pequenos e altamente modulares (nesse caso, usando as diretivas AngularJS, mas poderia ser facilmente WebComponents, componentes ReactJS ou qualquer outra tecnologia). Os componentes geralmente têm chamadas de API REST assíncronas, na inicialização ou na interação do usuário. Esse design está causando muitas chamadas de API por página (às vezes 20 ou mais). Existe algum problema com este design? Alguns estão sugerindo que condensemos as chamadas da API em serviços maiores do lado do cliente que atuam como singletons. Portanto, 10 chamadas de API podem ser reduzidas a 1, mesmo que uma página possa usar apenas uma parte desses dados. Existem bandeiras vermelhas ou problemas com este design? Qual deve ser preferido?

rest api async

— Ryan Langton
fonte

Acho que muito disso depende da latência que você experimenta e do impacto que isso causa no usuário (eles percebem)?

— Niall

São chamadas assíncronas e a maioria ocorre de uma só vez (inicialização da página). Portanto, o usuário vê apenas uma tela ligeiramente acinzentada e uma barra de carregamento até que todos os dados sejam carregados. Eu acho que é uma boa experiência do usuário. Minha única preocupação é o volume de chamadas do servidor, isso é um problema (limitações da API? Etc). Em um aplicativo tradicional, eu faria uma única chamada para o servidor por página.

— Ryan Langton

1

Não conheço nenhuma limitação de imediato. Parece uma troca; design vs. manutenção vs. latência vs. etc. Prefiro menos, mas todos os dados ainda são relevantes para a chamada (ou seja, se os dados necessários não forem relevantes para a chamada da API, faça-a separadamente). Admito, acho que este é um 6 de um, meia dúzia do outro.

— Niall

Considere atualizar seu servidor para HTTP 2.

— CodesInChaos

2

Navegadores limitam o número total de solicitações simultâneas

/programming/561046

Então, sim, há um problema com esse design. No entanto, acho que a resposta aceita é mudar para uma implementação de soquetes da web em que você usa uma única conexão, mas com muitos tipos de mensagens para se comunicar com o servidor

— Ewan
fonte

1

Isso não parece ser um problema, pois o limite é por navegador. Portanto, se houver mais de 6 chamadas, as outras serão colocadas na fila. Concordou que a conexão do soquete da Web seria mais eficiente, mas não tenho certeza se necessário.

— Ryan Langton

depende de como você está usando essas chamadas, eu acho. O principal problema é que, à medida que o código do lado do cliente se torna cada vez mais complicado, você começa a se deparar com as limitações do javascript. por exemplo. codificação de um pool de conexão cliente de soquete em uma linguagem projetada para mudar a cor do texto em uma mouseover

— Ewan

"Então, sim, há um problema com esse design" - isso parece uma declaração geral demais. Existem várias maneiras de implementar esse design com êxito.

— Richard

2

Esse design está causando muitas chamadas de API por página (às vezes 20 ou mais). Existe algum problema com este design?

Não deveria haver. O fato de cada solicitação ser pequena e assíncrona significa que você pode acelerar bastante o seu aplicativo Web, em vez de esperar uma única solicitação grande para concluir, que bloqueia tudo.

Apenas certifique-se de que seu javascript esteja corretamente assíncrono e possa fazer as coisas enquanto seus outros pedidos estiverem aguardando, e você terminará com um aplicativo muito melhor do que se tivesse um pedido enorme que buscava tudo.

Depois que todos os navegadores foram projetados para lidar com o carregamento de muitos URLs em conjunto, mesmo uma página da Web padrão típica pode ter dezenas ou centenas de solicitações de imagens, css, javascript, iframes etc.

— Cormac Mulhall
fonte

1

Não esqueça o tamanho de cada solicitação de rede. Geralmente, se cada solicitação retornar apenas 2 KB de dados, a solicitação de rede será muito cara para essa pequena quantidade de dados.

Se a solicitação de rede atingir 400KB, divida-a em duas. Mas, geralmente, não há dados suficientes para uma única solicitação de rede.

— dman
fonte

0

Algumas considerações aqui:

atuação

Se você está vendo um desempenho aceitável, não deve se preocupar muito com isso. Se você conseguir executar o HTTP2, verá um aumento no desempenho. ^[1] .

Projeto

Como em qualquer design, não há regras rápidas e rígidas sobre se você deve fazer muitos pedidos pequenos ou pedidos grandes. Algumas coisas a considerar:

Muitas das chamadas são interdependentes? Se você tiver um relacionamento de dependência complexo entre chamadas diferentes, isso poderá dificultar a manutenção. Se esse for o caso, os dados de resposta relacionados ao lote farão sentido.
Componentes diferentes compartilham grande parte dos mesmos dados? Se esse for o caso, você poderá ter um ponto central que faça as chamadas compartilhadas e permita que os componentes acessem os dados compartilhados.
Fique de olho na carga de manutenção dos componentes pequenos, fazendo chamadas separadas. Você saberá quando se tornar difícil de gerenciar e poderá ser necessária uma alteração. Alterar um projeto com base em necessidades futuras hipotéticas pode causar erros de projeto, porque você precisa antecipar com precisão quais problemas você terá no futuro. Se estiver funcionando bem agora, a alteração também seria desnecessária.

1: "O HTTP / 2 é totalmente multiplexado, permitindo a transferência de vários arquivos e solicitações ao mesmo tempo, em oposição ao HTTP1.x, que aceita apenas uma única solicitação / conexão por vez. O HTTP / 2 usa a mesma conexão para transferir diferentes arquivos e solicitações, evitando a operação pesada de abrir uma nova conexão para cada arquivo que precisa ser transferido entre um cliente e um servidor ". - https://css-tricks.com/http2-real-world-performance-test-analysis/

— Tjaart
fonte