Arquitectura web 2.0 desacoplada

Aínda coa utilización do patrón MVC, a interacción do usuario non resultaba todo o dinámica e fluída que se esperaba se a comparabamos coas aplicacións de escritorio e as xa masivamente implantadas en aplicacións móbiles.

Ademais xurdiron múltiples dispositivos nos que a nosa aplicación pode ser executada: ordenadores de sobremesa, portátiles, tablets, móbiles, consolas, televisores,...

Ao querer dar resposta aos novos retos formulados, na maioría de aplicacións web o teórico desacoplamento da vista do modelo MVC non era tal.

Para poder dar realizar este desacoplamento deberemos separar totalmente o backend e o frontend en dúas aplicacións web diferentes.

Tanto para o desenvolvemento de backend como o de frontend utilízanse frameworks.

Nesta arquitectura, xeralmente o backend é unha API REST.

Funcionamento

1. Carga inicial. O navegador recibe un ficheiro HTML básico que inclúe un script JavaScript co framework (por exemplo, react.js ou vue.js). Este script inicializa a aplicación.
2. Renderizado dinámico. O framework crea a interface (a vista) dentro dunha etiqueta HTML, normalmente <div id="app"> ou similar. En vez de cargar páxinas completas desde o servidor, o framework manexa as vistas dentro do navegador, cambiando só o necesario.
3. Interaccións do usuario. Cando o usuario interactura coa interface, o framework actualiza só as partes afectadas da páxina sen recargala enteira.
4. Comunicación co backend. Para obter ou enviar datos (ex. usuarios, produtos…), o framework fai chamadas HTTP (AJAX) ao backend. O backend responde con datos (JSON) e o framework actualiza a vista en tempo real.

Tecnoloxías relacionadas

API-REST

Unha API Rest, ou API RESTful, é unha interface de aplicacións que se axusta os límites da arquitectura REST e permite a interacción con servizos web RESTful. Unha API-REST utiliza como método de comunicación o protocolo HTTP/HTTPS.

As APIs son conxuntos de definicións e protocolos que se utilizan para deseñar e integrar software. Considérase unha especie de contrato entre o provedor de información e o usuario, onde se establece o contido que necesita o consumidor (a chamada) e o que require o produtor (resposta). Por exemplo, o deseño dunha API de servizo meteorolóxico podería requirir que o usuario escribira un código postal e o produtor dera como resposta a temperatura máxima e mínima.

Algúns conceptos relacionados cunha API-REST son os seguintes:

• Un cliente ou consumidor son usuarios que desexan acceder a información. Este pode ser unha persoa ou un programa.
• Os recursos é a información que a API proporciona os seus clientes. Esta pode ser de calquera tipo de datos: imaxes, vídeos, texto, etc. Xeralmente os recursos son textos en formato JSON ou XML.

Os seus principais principios son:

• Arquitectura cliente-servidor.
• Ausencia de estado (Stateless aplicattion). O estado gárdase e mantense no cliente e non no servidor (polo tanto non é posible utilizar sesións de servidor). Polo tanto as solicitudes deben prover toda a información necesaria para poder realizarse nun servidor que non mantén estados, polo que non garda contexto entre chamadas do mesmo cliente.
• Habilitación e uso da caché. Todas as solicitudes deben declarar se son ou non cacheables utilizando o encabezado cache-control de HTTP.
• Identificación de recursos nas peticións. O tipo de formato dos recursos (JSON, XML, etc.) pódese identificar nas cabeceiras HTTP.
• Mensaxes autodescriptivas: o cliente non debería de necesitar información adicional noutra mensaxe para poder entender unha mensaxe.

API-REST para probas

Existen webs como Requres que nos proporcionan unha API-REST para a realización de probas.

GraphQL

GraphQL é unha tecnoloxía creada no 2012 por Facebook para crear APIs dunha maneira similar a REST, pero cun enfoque distinto:

• En REST accedes á información a través de endpoints fixos (/usuarios, /produtos, /pedidos…), e o servidor decide que datos che devolve.
• En GraphQL só tes un endpoint único (ex. /graphql), e es ti, como cliente, quen decide exactamente que datos queres recibir e en que formato.

En REST, se queres obter o nome do usuario e os títulos dos seus posts:

• Chamas a /usuarios/1 → obtés todos os datos do usuario (nome, email, dirección, etc.).
• Chamas a /usuarios/1/posts → obtés todos os posts, quizais con moita máis info da que precisas (texto completo, datas, etc.).

En GraphQL, farías unha soa petición ao endpoint /graphql cunha consulta (parecida a SQL, pero en JSON):

{
  usuario(id: 1) {
    nome
    posts {
      titulo
    }
  }
}

E a resposta sería exactamente o que pediches, nin máis nin menos:

{
  "data": {
    "usuario": {
      "nome": "Ana",
      "posts": [
        { "titulo": "O meu primeiro post" },
        { "titulo": "Aprendendo GraphQL" }
      ]
    }
  }
}

Vantaxes:

• Pides só o que precisas → nin exceso de datos (overfetching) nin falta de datos (underfetching).
• Reducción das chamadas á API → podes traer datos relacionados nunha soa petición.
• Máis flexibilidade para o cliente → web, móbil ou calquera aplicación poden pedir distintos datos ao mesmo endpoint.
• Autodescritivo → a API leva un esquema que se pode explorar facilmente.

Desvantaxes:

• Maior complexidade inicial → require montar un servidor cun esquema definido.
• Non sempre máis eficiente → se as consultas son moi grandes ou complexas, poden cargar moito ao servidor.
• Cacheo máis complicado → en REST é doado cachear (/usuarios/1), pero en GraphQL, como as consultas poden variar, hai que implementar cacheo dun xeito máis avanzado.
• Curva de aprendizaxe → equipos acostumados a REST necesitan adaptarse.

Vantaxes do desacoplamento

Algunhas das vantaxes do desacoplamento son:

• Dotaron as interfaces web da mesma fluidez e interactividade das aplicacións de escritorio.
• O Backend pode ser utilizado por outras interfaces que non sexan web, como as aplicacións móbiles ou outras aplicacións de escritorio. Polo tanto os datos e a lóxica de negocio están centralizadas e expostas por unha mesma interface.
• O intercambio de información entre cliente e servidor é extremadamente lixeiro polo que cada petición e resposta entre cliente e servidor o que se intercambian son ficheiros JSON ou XML.
• Os frameworks de frontend están orientados a compentización e encapsulación. Deste xeito permiten crear grandes aplicacións a partir de pequenas pezas independentes.
• Os programadores de backend non necesitan coñecer HTML, CSS e JavaScript. E o mesmo acontece cos programadores de frontend que non necesitan coñecer as linguaxes de backend. Isto permite a especialización dos programadores.