desenv-web-rp.com

Vantagens / desvantagens de aplicativos Web "separados"

Estou no processo de projetar um aplicativo da Web PHP/MySQL bastante grande. Cheguei a uma bifurcação na estrada até a arquitetura interna; Posso criar o site como um aplicativo da Web "tradicional", onde, quando você faz uma solicitação, o servidor cria uma página HTML, envia a página inteira e o navegador a processa, ou eu posso compilar como um "separado" "aplicativo da web em que toda a estrutura HTML e o código do aplicativo são fornecidos ao navegador após o carregamento inicial, e o aplicativo usa retornos de chamada JavaScript para obter dados específicos ou emitir comandos por meio de uma API unificada. Além disso, pretendo que haja várias versões do site (desktop, celular, iPhone/Android móvel, compatível com mecanismos de pesquisa etc.) e, em algum momento, talvez até aplicativos móveis ou de desktop independentes.

Quais vantagens/desvantagens você tem, como desenvolvedores da Web, com cada uma dessas arquiteturas? Existe uma razão clara pela qual eu devo ir com um sobre o outro? É mais uma coisa de preferência dos desenvolvedores?

3
Adam Maras

Primeiro, se você usa um site pesado assíncrono ou não, isso não afetará muito sua capacidade de criar aplicativos para iPhone/Mobile e desktop, porque não tem nada a ver com eles. De qualquer forma, você não poderá reutilizar seu código.

Além disso, sites assíncronos podem ser tão lentos ou mais lentos que os sites normais. Normalmente, esse tipo de funcionalidade é adicionado por um motivo, especificamente para uma experiência aprimorada do usuário. O uso do JavaScript tende a prejudicá-lo no SEO, porque os webcrawlers não conseguem entender completamente a intenção do JavaScript e, portanto, ignoram-no principalmente.

Acho que o que você está procurando é uma maneira de reduzir as despesas gerais de desenvolvimento escrevendo apenas uma camada funcional (intermediária) uma vez e usando a mesma para todos os seus aplicativos. Nesse caso, acho que há valor, mas, francamente, esses tipos de arquiteturas são mais difíceis de configurar e levam muito tempo. Eu consideraria que você deve desenvolver seu site da melhor maneira possível e manter o código da camada intermediária o mais forte possível. Dessa forma, quando chegar a hora de adicionar um aplicativo para iPhone ou o que você puder, será mais fácil mudar para um modelo com um nível intermediário comum

O que estou realmente defendendo aqui é dar passos de bebê. Não tente escrever código agora para lidar com coisas que você ainda não conhece. Basta escrever o código que você precisa e torná-lo o mais flexível possível.

4
Ben Hoffman

Eu acho que a idéia de um aplicativo "separado" que depende muito de JavaScript/AJAX vai causar muitos problemas. Algumas coisas em cima da minha cabeça:

  1. Vai ser ruim para o SEO, já que o Google terá dificuldade em indexar qualquer coisa.
  2. Vai ser difícil torná-lo "favorito"
  3. Você terá dificuldades com os dispositivos móveis, pois muitos deles têm suporte a javascript muito limitado (ou quebrado).
5
Eric Petroelje

Primeiro, não se ofenda se essa resposta for óbvia ou básica demais. Seu uso de "separado" em vez de termos como Ajax ou jQuery me faz assumir menos experiência com este tópico. Claro que eu poderia estar interpretando mal a pergunta, então peço desculpas se for esse o caso.

Use ambos, mas sabiamente

Pense na sua escolha de tarefas do lado do servidor ou do cliente em termos de onde e como uma tarefa é realizada com mais eficiência. Isso o ajudará a renderizar páginas rapidamente (no servidor), mas transfere o trabalho para o navegador onde faz sentido. E haverá áreas cinzentas nas quais você apenas precisará fazer um julgamento. Seu trabalho é encontrar uma divisão inteligente do trabalho.

O que pertence ao lado do servidor?

(Este é um exemplo extremo para ilustrar o ponto.) Digamos que você esteja escrevendo um aplicativo Web que faça algum tipo de pesquisa. Você não escreve Javascript no navegador para chamar um serviço Web PHP no servidor para recuperar um banco de dados inteiro de 2 GB para "liberar o servidor" e descarregar a pesquisa na máquina do usuário. O que você faz é obter os termos de pesquisa do usuário com um formulário, POST de volta ao servidor para consultar o banco de dados diretamente e, em seguida, enviar os resultados de volta do servidor para o navegador.

A lógica aqui é que o próprio banco de dados sabe como fazer a consulta da melhor maneira, o servidor está mais próximo dos dados de origem e menos dados precisam ser movidos entre os componentes. O navegador precisa apenas do que é exibido, portanto, não envie tudo para o navegador. (Sem mencionar o desempenho relativo do idioma.)

O que pertence ao navegador?

O código do lado do navegador é o seu cenário "separado" (se bem entendi). Mas, para que o navegador faça quase tudo inteligente, ele precisa ter cooperação com o servidor.

Certo, você tem seu aplicativo de pesquisa funcionando, mas deseja aprimorá-lo com algumas calças elegantes do Ajax. Escreva um serviço da web PHP para pegar algumas letras e retornar termos de pesquisa correspondentes, à la o recurso "sugestão de pesquisa" do Bing , Google, etc. Escreva o código do navegador para sugerir termos somente depois que o usuário digitar três ou quatro letras, para que sua lista de sugestões seja pequena. De volta ao servidor, indexe seu banco de dados nesse campo para que a pesquisa seja rápida, rápida e rápida.

Aqui, o pensamento é que "a pesquisa sugere" é um recurso que deve ser dividido entre o servidor e o cliente. O navegador pode lidar rapidamente com pilhas de dados direcionadas e pequenas. O servidor pode obter essa pilha de dados direcionada e pequena e entregá-la ao cliente. Uma divisão ruim seria para o servidor renderizar uma lista de monstros (digamos, 500.000 itens) de possíveis valores de campo como uma ilha XML incorporada na página HTML e, em seguida, fazer com que o navegador pesquise conforme o usuário digita. (a) o envio de todos esses dados para o navegador é lento, (b) a pesquisa em Javascript nunca será tão rápida quanto permitir que o banco de dados procure, e (c) você provavelmente explodirá a máquina de um usuário colocando todos esses dados no espaço de aplicativos do navegador. Por outro lado, você precisa garantir que o Ajax chama o servidor e a consulta e o retorno subsequentes são super-rápidos. Nada de brincadeiras.

Onde fica a área cinza?

Aqui, novamente, é uma decisão judicial. Acima, falei sobre o servidor fazendo a pesquisa e enviando os resultados para o navegador. Mas, surge a pergunta: você permite que o navegador envie os termos de pesquisa com o formulário e o servidor renderize a página de resultados ou use o Ajax/Javascript do cliente para enviar os termos de pesquisa e recuperar os resultados, depois processe-os em um DIV para evitar uma atualização de página? Ambos são válidos. Em termos de recursos, não há benefício real de qualquer maneira. A maneira do Ajax pode proporcionar uma melhor experiência ao usuário, mas, dependendo do seu aplicativo e das circunstâncias, pode apresentar alguns outros desafios (por exemplo, segurança).

Bottom line

Use os dois adequadamente. Não economize em pensar e aprender sobre desempenho e eficiência arquiteturais. Mova menos dados, menos vezes. Você sobrecarregará seus servidores, bancos de dados e navegadores dos usuários.

2
b w

Para poder reutilizar o código, você sempre pode procurar no XSLT a geração de páginas de entrada e, em seguida, ter interfaces XML/JSON para AJAX (utilizando a interface XML para as páginas de entrada do XSLT).

Você normalmente permitiria que o conteúdo e a interação funcionassem em uma interface RESTful com o prefixo/json/... e/xml/... e hospedaria seu conteúdo principal, convertido em marcação via XSLT em/...

Dessa forma, as pessoas podem acessar qualquer página e, de repente, ter o site completo AJAX. As aranhas podem rastrear seu site e você se concentrou no conteúdo/nas interfaces, acima de tudo - parece uma vitória/vitória.

Às vezes, os sites para celular precisam de layouts diferentes (sites personalizados para iPhone, apenas para alguém?). Uma simples conversão XSLT aqui ou ali para diferentes usuários pode reutilizar tudo o que você fez até agora.

Lembre-se de projetar para saída e navegação HTML simples, as simplificações AJAX podem ser seguidas.

PS - Faça o lado do servidor das transformações XSLT

1
Metalshark