O primeiro passo no trabalho com a web é enviar dados para o aplicativo do servidor. E se a análise de uma dúzia de pequenas linhas pode ser confiada à estrutura, e quanto ao download de arquivos?
Vamos usar o PHP como exemplo, embora o descrito seja verdadeiro para 99% de outras linguagens e tecnologias. Suponha que desejemos permitir que o usuário envie fotos para o site, para isso, criamos um formulário com um campo do tipo file e ... Externamente, tudo é muito simples, apenas alguns bytes no formulário e no código foram alterados, mas agora você pode trabalhar com arquivos em vez de texto nos formulários! Mas nem tudo é tão simples, seu arquivo deve primeiro se instalar em algum lugar em / tmp / até que a solicitação chegue completamente, seu script simplesmente não controla e você não pode fazer nada a respeito. Por exemplo, em vez de uma imagem, o usuário enviou um arquivo exe, mas você só descobrirá isso depois que o download for finalmente concluído. Assim, um invasor pode martelar por um tempo um canal e o tempo do seu subsistema de disco, fingindo carregar arquivos úteis, e você nem o saberá. Se o servidor de armazenamento em cache estiver na frente do servidor de aplicativos, a situação será ainda pior: por exemplo, o nginx cria arquivos temporários, ou seja, primeiro, a solicitação do usuário será estabelecida no disco, assim que terminar, o arquivo será relido e entregue rapidamente ao servidor de aplicativos (no nosso caso, php), onde será salvo no disco UMA VEZ NOVAMENTE. Uso triplo total do disco, mesmo que o usuário precise apenas exibir a mensagem "você esqueceu de inserir o captcha".
Não estou falando do fato de que coisas mais divertidas com essa abordagem não podem ser feitas. Um recurso simples como a "barra de progresso do upload de arquivo" fica indisponível. Para exemplos mais complexos: o YouTube mostra quadros de um filme que ainda está carregando, mas não totalmente carregado. Você não terá nenhum controle (e até notificações!) Antes do download do filme inteiro (2 gigabytes, por exemplo). Você nem sabe que alguém comeu 1,5 gigabytes de disco, mas fechou o navegador ou clicou no botão de atualização no navegador sem esperar nada.
Obviamente, existem várias muletas de graus variados de curvatura que permitem resolver tarefas típicas, como "obter estatísticas de solicitação via json", implementadas como módulos de servidores da Web, mas essas coisas precisam ser feitas de forma independente e / ou, portanto, vinculadas ao ambiente, o aplicativo deixa de ser independente e torna-se dependente de aplicativos específicos e de suas bibliotecas.
Cache
Os caches são vitais. A técnica de armazenamento em cache permite acelerar a capacidade de resposta do site e reduzir a carga, eliminando a necessidade de realizar as mesmas operações para muitas solicitações. Por exemplo, quantos não fazem 2 + 2, sempre haverá 4, mas a computação 2 + 2 consome recursos do servidor, é muito mais lucrativo calcular esse valor 1 vez, quando o primeiro visitante chegar, e depois escrever em algum lugar, a fim de liberar esse outro usuário resultado.
Não confunda esse cache com cabeçalhos http, eles afetam apenas um cliente específico (no original também em proxies intermediários), enquanto o cache no servidor foi projetado para fornecer o mesmo conteúdo para muitos usuários.
Infelizmente, não é lucrativo fornecer armazenamento em cache a um servidor intermediário; no caso de uma menor atualização em uma página, você terá que criar uma página do zero e dadas realidades modernas, quando houver muitos elementos dinâmicos em uma página; na verdade, cada página será única e, por outro lado, uma solicitação no formato GET / somepage.html? someshit = 12345 romperá o cache e será formada uma nova página que nem levará em consideração esse parâmetro, mas, no entanto, haverá custos para sua criação, que novamente poderão ser usados por um invasor. Portanto, poucas pessoas usam servidores de cache intermediários e já é muito difícil confiar neles.
Resta armazenar em cache tudo o que está dentro do aplicativo, quase todas as estruturas fornecem suas próprias muletas, assim como outras já prontas, como todos os tipos de memosheds e coisas do gênero. Normalmente, desenvolvedores iniciantes apenas escrevem em água fervente quando descobrem que, ao gerar uma página, você pode fazer 500 solicitações ao cache de memórias e não haverá nada para isso (ao contrário do mysql favorito de todos). Como resultado, todo o código é coberto com wrappers, que primeiro verificam o resultado da solicitação no memcache e, em seguida, eles escalam após o resultado no mysql. Não discuto, o controle manual do cache é necessário, mas o controle completamente manual leva a possíveis erros, nos quais você pode simplesmente esquecer de ativar o cache, que, de acordo com a lei da maldade, será um local crítico.
Interfaces
Qual interface o site deve ter? Só não diga isso verde.
Anteriormente, como regra, a apresentação do site era única e indivisível. No entanto, em portais grandes havia botões "versão impressa" ou mesmo "versão wap", que mais tarde foi substituída pela "versão PDA" - já em HTML simples, apenas mais simples. Embora, dependendo de onde, se você usa o Twitter, essa é a única versão legível. O tempo passou e houve a necessidade de editar sites não apenas para impressoras e telefones, mas também para todos os tipos de iPads e geladeiras com suporte a HTML5. Naturalmente, tudo isso se apaixonou pelos desenvolvedores, porque eles precisavam fazer 10 versões de um site cada um e decidiram fazer algo universal. Um tipo de API para o site.
O que é uma API - eu não sei. Honestamente, eu não sei. Geralmente, esse é um tipo de merda quando você cospe em um servidor com um pedaço de string codificado por url e, em troca, recebe um pedaço de json / xml / plain text, que sorte ele tem. Obviamente, nenhum padrão, nem mesmo tipos de dados primitivos, pode ser qualquer coisa, um resultado vazio também pode ser qualquer coisa, de nulo a "" (aspas vazias), ou até estar ausente como resultado. É bom que os autores leiam sobre uma palavra como REST e se apressem em implementá-la, mas no contexto de tudo o mais, isso não faz sentido. A funcionalidade também não é clara: se, ao solicitar uma página HTML, pudermos obter tudo de uma vez (últimas notícias, comentários, curtidas etc.), quantas solicitações precisaremos fazer no caso de uma API - somente o autor dessa API sabe, é bem possível que os comentários podem ser recebidos, mas gosta deles - não. De fato, uma API é uma maneira de dividir o desenvolvimento de clientes e servidores em equipes de desenvolvimento completamente diferentes que interagem mal entre si. E não se pode falar sobre a utilidade dessa API.
E muitas vezes acontece que acessar a API requer uma certa chave. As chaves geralmente podem ser obtidas gratuitamente. Por que não pegar essa chave? O problema é que isso nos leva a contabilidade explícita de solicitações, a alguma contabilidade interna. E quem sabe quando o autor quer monetizar tudo isso? É possível que, após algum tempo, as chaves gratuitas sejam desativadas ou severamente limitadas, oferecendo o uso de uma tarifa paga. E, às vezes, em geral, a emissão de todas as chaves é suspensa e o serviço é interrompido, mesmo em uma base comercial, isso também acontece. Bem, por que uma API? É mais fácil para mim esticar a página e analisá-la com regulares do que suportar tal desgraça. Portanto, quase nunca uso essas APIs, principalmente porque não vou lidar com os recursos delas.