Video: Modelo Cliente Servidor, Explicación Simple (Noviembre 2024)
Una de las cosas que he encontrado interesantes en el mundo del desarrollo en los últimos meses es cómo las aplicaciones modernas están volviendo a colocar más inteligencia en el cliente en lugar del servidor. El modelo cliente-servidor no es nada nuevo, por supuesto: es la forma en que las aplicaciones tradicionales se han construido durante años, con aplicaciones cliente enriquecidas que se comunican con las aplicaciones del lado del servidor. Pero en la era de la Web, e incluso de la Web 2.0, el foco se movió a las aplicaciones web en las que la mayor parte de la inteligencia estaba en el servidor web (generalmente en servidores de aplicaciones basados en Java) y el cliente era solo una simple página web en un navegador donde cada vez que hace clic, carga una nueva página.
Pero recientemente, la maduración de HTML5, CSS y, en particular, JavaScript, está llevando a los desarrolladores a poner inteligencia real y procesamiento real en la página web. En particular, hemos visto el surgimiento de una variedad de marcos basados en JavaScript del lado del cliente que facilitan la creación de front-end inteligentes que se ejecutan completamente dentro de un navegador web moderno. Los navegadores involucrados son típicamente aquellos basados en el motor de Webkit, incluidos Chrome y Safari, pero la mayoría de las aplicaciones parecen funcionar bien en las versiones actuales de Firefox e Internet Explorer también. Termina con una página web más compleja que cambia dinámicamente, extrayendo datos del servidor según sea necesario.
Tres marcos MVC en particular parecen estar recibiendo la mayor atención: Backbone.js, Ember.js y Angular.js. (MVC significa controlador de vista de modelo: es esencialmente la arquitectura detrás de la informática del cliente web. El "js" significa JavaScript). Esencialmente, esto es una consecuencia del enfoque AJAX (JavaScript asíncrono y XML) popular durante la última década o así, pero cada vez más maduro y casi estandarizado. La idea es poner más estado e inteligencia en el navegador, luego hacer que el navegador se conecte con las API REST en el lado del servidor.
Backbone es quizás el más básico y mínimo de estos frameworks; Se utiliza en diversos grados por muchos sitios populares. Ember surgió de un marco llamado Sproutcore que Apple respaldaba, y es un marco mucho más completo diseñado para permitirte hacer aplicaciones de escritorio. A menudo se usa con Bootstrap, un conjunto de plantillas para HTML y CSS creado originalmente por empleados de Twitter. Angular es la alternativa de Google que parece estar en algún punto intermedio: algunas personas piensan que es un poco más flexible o al menos "menos obstinado" que Ember pero más completo que Backbone. (Tenga en cuenta que Google está presionando a los desarrolladores para que usen Angular para mejorar la calidad de la codificación, pero internamente en realidad usa un conjunto de marcos diferente y patentado). Incluso Microsoft ha agregado ganchos en Visual Studio para estos marcos.
Siendo esta la Web, hay docenas de alternativas. Uno de los más interesantes que he escuchado últimamente es Meteor, diseñado para funcionar con JavaScript tanto en el lado del cliente como del servidor. Pero esto todavía es muy temprano, y aún no conozco a ningún usuario real. Mientras tanto, más desarrolladores están jugando con Node.js, a menudo utilizado para implementaciones de JavaScript del lado del servidor.
La ventaja de tales marcos parece clara. Las aplicaciones de cliente web enriquecidas son más potentes que las aplicaciones de cliente ligero, donde todo se ejecuta en el servidor, pueden proporcionar una mejor interfaz de usuario y ofrecen la posibilidad de obtener información fuera de línea. Con estos marcos, puede crear aplicaciones de cliente web enriquecidas mucho más rápido de lo que podría, creando todo desde cero y aprovechando las comunidades que se desarrollan alrededor de cada uno de ellos.
Quizás lo más importante es que puede crear aplicaciones móviles que se escalen a diferentes dispositivos sin tener que escribir aplicaciones nativas específicas. Todavía hay un buen argumento para las aplicaciones nativas, que pueden abordar más directamente las características específicas de cada plataforma. Sin embargo, muchos desarrolladores han descubierto que dichos marcos pueden acelerar drásticamente el desarrollo multiplataforma, particularmente cuando se usan junto con cosas como PhoneGap, un marco móvil de código abierto comprado por Adobe y de código abierto en el proyecto Apache Cordova.
Por supuesto, los dispositivos móviles tienen sus propias limitaciones, incluida la velocidad de los procesadores y, lo que es más importante, la velocidad de la conectividad, y a veces la falta de ella. Una de las razones por las que a las personas les gustan las aplicaciones en las páginas web es que a menudo puedes descargar la funcionalidad básica a través de Wi-Fi o una conexión rápida y simplemente descargar los datos que necesitabas, no todo el diseño. Los paquetes como PhoneGap resuelven este problema poniendo el JavaScript en una aplicación descargada.
Sin embargo, existen otros problemas con dichos marcos. Por definición, hacer más computación en el lado del cliente aumenta la complejidad en comparación con una aplicación simple de solo servidor, y de hecho, algunos de los inconvenientes del antiguo modelo cliente-servidor sí regresan. Los desarrolladores necesitan administrar el estado en ambos lados. El código en dos lugares significa que debe centrarse en la seguridad en ambos lugares. Dado que un equipo de desarrollo a menudo tiene algunas personas que trabajan en el cliente y otras en el servidor, obtiene problemas de comunicación adicionales. Por otro lado, algunos de los problemas más antiguos del cliente-servidor no vuelven y, en cambio, conserva los beneficios del software web. Este es un mundo mucho más basado en los estándares y en la comunidad, por lo que no depende tanto de un entorno propietario único. Al dividir las porciones del lado del cliente y del servidor, también puede tener una implementación más limpia y simple del lado del servidor que solo procesa y no UI, y como resultado puede requerir menos recursos. Sin embargo, aún tiene la ventaja de poder actualizar todos los clientes a la vez, ya que normalmente el navegador carga el código del servidor cuando se invoca la aplicación.
Claramente estamos viendo un movimiento hacia clientes web más inteligentes, no en todos los casos, sino en muchas aplicaciones nuevas. Es mucho más difícil tomar aplicaciones antiguas y moverlas a este modelo, pero también estamos viendo algo de eso. No es el viejo modelo cliente-servidor, pero se está acercando mucho más.
