Mas o que eu acredito muito é que todos os temas que eu abordei nessas perguntas são temas que vão ser abordados ou que são abordados durante os processos seletivos para desenvolvedores Full Stack Júnior.
Então é muito bacana vocês saberem a resposta dessas perguntas que eu vou trazer aqui, mas o mais importante de tudo é compreender o tema que está sendo abordado.
A arquitetura cliente-servidor é uma arquitetura muito utilizada em aplicações web, onde normalmente se divide a responsabilidade do sistema entre um cliente e o servidor.
Enquanto o servidor é responsável por receber esses pedidos do cliente, processar essas solicitações, normalmente consultando no banco de dados e ficando responsável pela lógica de negócios e retornando uma resposta.
E essas requisições normalmente vão ser disparadas pelo nosso front-end através da interação com o usuário ou carregamento da página, que vai chegar no nosso servidor que ficou ouvindo essas requisições o tempo todo, processa elas e normalmente retorna uma resposta, tudo via protocolo HTTP, para que o front-end utilize esses dados ou utilize essa informação para exibir algum dado para o usuário.
Lembrando que ao longo desse vídeo eu vou dar só umas respostas simplificadas, porque a ideia aqui não é fazer um vídeo exclusivo para cada um dos temas, é como se fosse mesmo perguntas de entrevista onde a gente precisa ser conciso, mas ao mesmo tempo dar a resposta correta.
Basicamente, o navegador vai ficar aguardando essa resposta em segundo plano, mas ao longo disso, o usuário pode continuar interagindo com a tela, o processamento de outras linhas de código não é travado por conta dessa chamada.
E assim que a resposta chega no nosso navegador, normalmente ela é tratada por uma função de callback ou uma promise, que é responsável por pegar esses dados e então atualizar a tela ou atualizar todos os contextos necessários e requisitaram aquela informação para o servidor.
E é isso que garante uma experiência mais fluida para os usuários que utilizam a aplicação ali na web, porque eles não veem uma página travada ou congelada toda vez que há uma interação entre o cliente e o servidor ou entre o back-end e o front-end.
A intenção do path parameter é acessar um recurso específico da nossa API ou do nosso servidor, então quando nós utilizamos um path parameter, esse path parameter pode ser estático, como por exemplo, /api/users.
Mas eu poderia fazer /api/users/um UUID, né, que seria o ID daquele usuário, esse ID, ele é dinâmico, eu posso para cada usuário mandar um valor diferente, mas percebam que eu estou tentando acessar um recurso de um usuário específico, então essa é a intenção do path parameter.
Order by date of creation, ordenar pela data de criação, tudo isso fazendo uma query para os usuários, por exemplo, então eu poderia fazer um GET, né, agora dando um exemplo com o método HTTP, eu poderia fazer um GET onde eu estou fazendo uma busca para /api/users.
Passando o query parameter de order by date creation, então eu estou buscando ali o path parameter /api/users, fazendo, né, uma ordenação pela data de criação através do query parameter de order by.
E um detalhe muito importante, tanto os path parameters quanto os query parameters, a gente que define na nossa aplicação, então quando a gente está criando o nosso back-end, por exemplo, definindo a nossa estrutura dos nossos endpoints, nós definimos qual path parameter nós aceitamos e qual query parameter nós aceitamos também.
Isso acontece porque em bancos de dados relacionais, a gente não consegue conectar diretamente múltiplos registros de uma tabela com múltiplos registros de outra tabela de forma limpa, e em muitas vezes a gente usa essa abordagem de criar uma tabela intermediária, que nesse caso é a tabela Post Influencer, que ela acaba sendo uma tabela de junção que a gente chama.
É uma tabela que existe para armazenar a relação entre duas entidades que têm uma relação N para N, e normalmente ela pode ali também agregar outras colunas, né, outras informações que dizem respeito àquela relação.
Então, por exemplo, a coluna commission rate é uma coluna que não existe nem na tabela influencer nem na tabela post, porque ela não faz sentido existir, a comissão que o influencer recebeu de um post não faz sentido pertencer nem a tabela que descreve o influencer nem a tabela que descreve o post.