Quais são as vantagens de uma arquitetura cliente / servidor em aplicativos da Web em oposição a um aplicativo de front-end gerado pelo servidor


13

Em nossa empresa, precisamos construir uma interface da web em uma plataforma Linux incorporada. Eu meio que vejo duas opções: você usa uma tecnologia em que o HTML e o JavaScript são gerados no lado do servidor (pense em JSP, Grails, mas é algo que está usando C ++ e gera HTML / JavaScript) ou você cria um 'cliente' em HTML5 aplicativo que fala com um back-end gerador de JSON ou XML.

Tenho a sensação de que os aplicativos da Web atualmente tendem a acompanhá-lo, mas quais são as vantagens de fazê-lo (os desenvolvedores do projeto escolhem o primeiro, principalmente com base no fato de conhecerem C ++ muito melhor que HTML e Javascript)


Se os desenvolvedores estão mais familiarizados com C ++ do que com HTML + JS, por que eles adotaram a solução anterior? O último lhes daria menos problemas, especialmente se eles substituíssem o "HTML 5 Client" por um cliente rico, como um aplicativo de desktop C ++, ou um aplicativo de desktop implementado Java Applet ou JNLP ...?
Shivan Dragon

Respostas:


4

AJAX

Acho que sua pergunta se resume a: "Meu aplicativo Web deve gerar HTML no lado do cliente ou no servidor?" A geração do lado do cliente se comunica com o servidor usando AJAX, embora o X (XML) geralmente tenha sido substituído pelo JSON, mas a maioria das pessoas ainda o chama de AJAX porque soa melhor. No lado do servidor, o servidor apenas cria HTML no servidor.

Tenho muita experiência com XML e quase nenhuma com JSON. Tudo o que sei sobre XML me faz sugerir que você use JSON, se possível.

Profissionais do AJAX:

  • Envie menos dados por HTTP (S) para que eles possam executar mais rapidamente.
  • O servidor é essencialmente um serviço da web para que outras pessoas (ou você) possam escrever seus próprios clientes. Isso pode ajudar ao criar uma versão móvel do seu site. Além disso, muitas invenções se tornam populares por razões que seu criador nunca pretendeu. Os serviços são mais amigáveis ​​para as pessoas que encontram novos usos para o seu código.
  • Parece um aplicativo mais recente

Contras AJAX:

  • Depurando JavaScript
  • Complexidade?
  • O que você pode fazer com JavaScript geralmente é completamente impossível para pessoas cegas ou deficientes usarem.
  • Pode exigir mais código total (armazenamento geral maior no seu dispositivo incorporado)

Servidor cliente

Todos os aplicativos da web usam a arquitetura cliente-servidor. O protocolo HTTP força os aplicativos da web a se comportarem dessa maneira. O AJAX usa uma solução alternativa para essa limitação de design, mas o modelo básico subjacente do HTTP ainda é cliente-servidor. Eu não ficaria muito preocupado com a melhor maneira de aplicar o MVC a aplicativos da web. Se você precisa fazer o MVC por razões políticas, veja como o Ruby / Rails faz isso. Na verdade, o Rails é uma ótima arquitetura para copiar (ou usar).

Serviço versus aplicativo.

Um bom serviço é quase sempre melhor que um aplicativo. Mas fazer um bom serviço é difícil! Pode ser necessário fazer o aplicativo antes de poder escrever uma especificação projetada o suficiente para um serviço. Não faça seu trabalho mais difícil do que precisa. Para a versão 1, concentre-se em criar um ótimo aplicativo. Até que seu aplicativo seja relativamente estável e você tenha certeza de que atende aos requisitos do usuário, ter um serviço provavelmente não fará nenhum bem. Projetar o serviço errado muito cedo é um desperdício de tempo que continua desperdiçando enquanto você tenta consertar sua interface de serviço e lida com a refatoração maciça do código do servidor e do cliente a seguir.

C / Web

Uau. Trabalhei em C e Assembly por 3 anos antes de mudar para o desenvolvimento web. Não consigo pensar em uma linguagem pior para escrever um aplicativo da Web - especialmente do ponto de vista da segurança. A validação de entrada e o escape de saída são tão críticos ... O SANS libera uma lista dos erros mais comuns a cada ano. Estouros de buffer, injeções, problemas entre sites (codificação de saída incorreta) ... Todos esses erros são realmente fáceis de cometer em C ou montagem. Pelo menos uma linguagem como Java possui uma String que é imune a estouros e um mecanismo de tratamento de exceções que geralmente evita que erros um por um permitam que códigos mal-intencionados acessem a memória do sistema. Sem mencionar o manuseio de conjuntos de caracteres internacionais (use UTF-8 quando possível).

Se você precisar usar o C por motivos de memória ou firmware, é isso que você deve fazer. Seja cuidadoso!

Suporte do navegador

O primeiro passo para criar um aplicativo Web é descobrir quais navegadores serão usados ​​pelos seus clientes? W3Schools e Wikipedia são boas fontes de estatísticas gerais, mas o YMMV.

Onde trabalho agora, atualmente validamos que nosso aplicativo apenas cria HTML de transição XHTML 1.0 válido. Também usamos o Doctype e a formatação específicos necessários para evitar o Modo Quirks no IE, o que facilita a gravação em HTML entre navegadores (consulte as dicas no meu blog ). Testamos as 3 versões mais recentes do IE, além do Firefox e Chrome no Windows e Linux (o Safari usa o mesmo mecanismo de renderização do Chrome). Com essa validação e teste, nosso aplicativo funciona praticamente em qualquer lugar (Windows, Mac, Linux, iPhone, Android, etc.), exceto o BlackBerry.

O BlackBerry nunca teve um navegador real com JavaScript, por isso não o apoiamos. Os usuários do BlackBerry estão acostumados a não ter um navegador da Web real, para não reclamarem. Talvez isso esteja mudando? Gostaria de perguntar a alguns clientes quais navegadores eles estão usando e não se esqueça de testar com esses navegadores.

Sumário

Todos os sites são criados em HTML e HTTP. Tenha uma boa referência para essas tecnologias em mãos enquanto estiver fazendo seu aplicativo. No decorrer da criação de um aplicativo, mesmo com um kit de ferramentas, você encontrará problemas que exigem um entendimento básico dessas tecnologias para resolvê-las.

Você provavelmente também precisa se sentir confortável com CSS e compactação de imagem para criar algo que pareça decente e responda rapidamente. JavaScript, servidores da web e navegadores são áreas adicionais de conhecimento que você precisará.

Se você criar seu HTML no lado do servidor, sua base de códigos provavelmente será menor e talvez você não precise aprender JavaScript. O modelo do lado do servidor significa que seus programadores escreverão um código (C?) Que gera HTML que eles podem ver diretamente antes de serem enviados ao cliente. O modelo AJAX significa que seus programadores estarão escrevendo JavaScript que gera HTML. Não conheço muitas ferramentas para validar ou mesmo exibir o código HTML gerado pelo JavaScript em um navegador, dificultando a programação correta.

Onde trabalho agora, usamos uma abordagem híbrida que ocasionalmente envolve código Java que gera JavaScript e HTML. Se vocês são novos no desenvolvimento web, esse não é o lugar para começar. Acho que devo dizer que, a menos que você tenha razões convincentes para usar um modelo AJAX, eu começaria com o modelo mais antigo de geração HTML do lado do servidor e veria até onde ele chega.


"Não conheço muitas ferramentas para validar ou até mesmo visualizar o código HTML gerado pelo JavaScript em um navegador" É para isso que serve o FireBug (ou qualquer outra extensão de navegador de desenvolvedor da Web, como as ferramentas de desenvolvedor da Web do Chrome).
sleske

13

O último tem a vantagem de tornar seu "back-end" um "serviço de dados" genérico (o que isso pode significar no seu contexto).

Seu cliente HTML é então apenas um dos muitos possíveis consumidores desses dados. Pense nos aplicativos iOS, Andriod, Windows 8, APIs etc. - como outros consumidores.


Além disso, embora possa ser uma faca de dois gumes (mais coisas dependem da API, o que dificulta a atualização), também ajuda a unificar o código do lado do servidor, em vez de manter um conjunto de APIs "web" e "API" "controladores e visualizações. Separação de preocupações FTW.
Shauna

6

Uma maneira comum crescente de um aplicativo Web é uma mistura de ambos, tendendo um ou outro lado.

A primeira abordagem é mais tradicional, existe há anos e está bem documentada (embora o c ++ geralmente não seja uma linguagem popular para isso).

A segunda opção é mais moderna e está presente nos blogs e fóruns de desenvolvimento atualmente. Uma das razões para isso é a crescente necessidade de servir o mesmo aplicativo para outras interfaces, API móvel e de serviços. A segunda abordagem tende a um cliente mais rico e responsivo.

Em suma, isso depende de outras restrições, como a familiaridade da equipe e o caso de negócios.

Algumas perguntas que podem ajudá-lo a avaliar suas opções:

  1. A equipe tem experiência no idioma e na plataforma?
  2. A equipe está disposta a aprender novas abordagens e tecnologias?
  3. O aplicativo tira vantagens de ser mais facilmente programável para outros dispositivos (iPhone, Android, Windows 8, etc.)
  4. Outro aplicativo interno ou externo integrado aos serviços ou dados estará disponível para o aplicativo?

5

Para aplicativos "intranet", eu uso a abordagem de cliente gordo (JavaScript / HTML5-app + JSON) com o ExtJS4.

Para sites normais da "internet", eu usaria uma abordagem mais "clássica".

Os clientes precisam renderizar o site de qualquer maneira, então, por que não cobrá-los com todo o processo e fornecer apenas os dados a serem preenchidos? Simplesmente, o código do servidor é gerado para gerar respostas (apenas JSON ou XML), o que economiza desempenho. Além disso, como sempre há mais clientes do que servidores, todo o sistema é muito melhor se mais trabalho for feito pelos clientes.

O código do cliente é entregue com HTTP; você ainda pode enviar facilmente novas versões para os usuários sem nenhum mecanismo de atualização obscuro. (Apenas substitua o HMTL / JS / CSS)

A única razão pela qual eu preferiria uma abordagem clássica em sites normais, são os mecanismos de pesquisa.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.