031.2 Lección 1
Certificación: |
Conceptos básicos de desarrollo web |
---|---|
Versión: |
1.0 |
Tema: |
031 Desarrollo de software y tecnologías web |
Objetivo: |
031.2 Arquitectura de aplicaciones web |
Lección: |
1 de 1 |
Introducción
La palabra aplicación tiene un significado amplio en la jerga tecnológica. Cuando la aplicación es un programa tradicional, ejecutado localmente y autosuficiente en su propósito, tanto la interfaz operativa de la aplicación como los componentes de procesamiento de datos se integran en un solo “paquete”. Una aplicación web es diferente porque adopta el modelo cliente/servidor y su parte cliente se basa en HTML, que se obtiene del servidor y, en general, se procesa mediante un navegador.
Clientes y servidores
En el modelo cliente/servidor, parte del trabajo se realiza localmente en el lado del cliente y parte del trabajo se realiza de forma remota, en el lado del servidor. Las tareas que realiza cada parte varían de acuerdo con el propósito de la aplicación, pero en general depende del cliente proporcionar una interfaz al usuario y diseñar el contenido de una manera atractiva. Depende del servidor ejecutar la aplicación, procesando y respondiendo a las solicitudes realizadas por el cliente. En una aplicación de compras, por ejemplo, la aplicación cliente muestra una interfaz para que el usuario elija y pague los productos, pero la fuente de datos y los registros de transacciones se mantienen en el servidor remoto, al que se accede a través de la red. Las aplicaciones web realizan esta comunicación a través de Internet, generalmente a través del Protocolo de transferencia de hipertexto (HTTP).
Una vez cargada por el navegador, el lado del cliente de la aplicación inicia la interacción con el servidor siempre que sea necesario o conveniente. Los servidores de aplicaciones web ofrecen una interfaz de programación de aplicaciones (API) que define las solicitudes disponibles y cómo se deben realizar. Por lo tanto, el cliente construye una solicitud en el formato definido por la API y la envía al servidor, que verifica los requisitos previos para la solicitud y devuelve la respuesta adecuada.
Si bien el cliente, en forma de aplicación móvil o navegador de escritorio, es un programa autónomo con respecto a la interfaz de usuario y las instrucciones para comunicarse con el servidor, el navegador debe obtener la página HTML y los componentes asociados, como imágenes, CSS y JavaScript: que definen la interfaz y las instrucciones para comunicarse con el servidor.
Los lenguajes de programación y las plataformas que utilizan el cliente y el servidor son independientes, pero utilizan un protocolo de comunicación mutuamente comprensible. La parte del servidor casi siempre la realiza un programa sin una interfaz gráfica, que se ejecuta en entornos informáticos de alta disponibilidad para que siempre esté listo para responder a las solicitudes. Por el contrario, la parte del cliente se ejecuta en cualquier dispositivo que sea capaz de representar una interfaz HTML, como los teléfonos inteligentes.
Además de ser imprescindible para determinados fines, la adopción del modelo cliente/servidor permite que una aplicación optimice varios aspectos de desarrollo y mantenimiento, ya que cada parte puede diseñarse para su propósito específico. Una aplicación que muestra mapas y rutas, por ejemplo, no necesita tener todos los mapas almacenados localmente. Solo se requieren mapas relacionados con la ubicación de interés de los usuarios, por lo que solo esos mapas se solicitan al servidor central.
Los desarrolladores tienen control directo sobre el servidor, por lo que también pueden modificar el cliente que les proporciona. Esto permite a los desarrolladores mejorar la aplicación, en mayor o menor medida, sin necesidad de que el usuario instale explícitamente nuevas versiones.
El lado del cliente
Una aplicación web debe ejecutarse de la misma manera en cualquiera de los navegadores más populares, siempre que el navegador esté actualizado. Algunos navegadores pueden ser incompatibles con innovaciones recientes, pero solo las aplicaciones experimentales utilizan características que aún no se han adoptado ampliamente.
Los problemas de incompatibilidad eran más comunes en el pasado, cuando los diferentes navegadores tenían su propio motor de renderizado y había menos cooperación en la formulación y adopción de estándares. El motor de renderizado es el componente principal del navegador, ya que es responsable de transformar HTML y otros componentes asociados en los elementos visuales e interactivos de la interfaz. Algunos navegadores, en particular Internet Explorer, necesitaban un tratamiento especial en el código para no interrumpir el funcionamiento esperado de las páginas.
Hoy en día, existen diferencias mínimas entre los principales navegadores y las incompatibilidades son raras. De hecho, los navegadores Chrome y Edge usan el mismo motor de renderizado (llamado Blink). El navegador Safari y otros navegadores que se ofrecen en la App Store de iOS utilizan el motor WebKit. Firefox usa un motor llamado Gecko. Estos tres motores representan prácticamente todos los navegadores que se utilizan en la actualidad. Aunque se desarrollan por separado, los tres motores son proyectos de código abierto y existe una cooperación entre sus desarrolladores, lo que facilita la compatibilidad, el mantenimiento y la adopción de estándares.
Debido a que los desarrolladores de navegadores se han esforzado mucho para mantener la compatibilidad, el servidor normalmente no está vinculado a un solo tipo de cliente. En principio, un servidor HTTP puede comunicarse con cualquier cliente que también sea capaz de comunicarse a través de HTTP. En una aplicación de mapas, por ejemplo, el cliente puede ser una aplicación móvil o un navegador que carga la interfaz HTML desde el servidor.
Variedades de clientes web
Hay aplicaciones móviles y de escritorio cuya interfaz se procesa a partir de HTML y, al igual que los navegadores, pueden usar JavaScript como lenguaje de programación. Sin embargo, a diferencia del cliente cargado en el navegador, el HTML y los componentes necesarios para el funcionamiento del cliente nativo están presentes localmente desde la instalación de la aplicación. De hecho, una aplicación que funciona de esta manera es prácticamente idéntica a una página HTML (es probable que ambas sean procesadas por el mismo motor). También existen aplicaciones web progresivas (PWA), un mecanismo que le permite empaquetar clientes de aplicaciones web para su uso sin conexión, limitado a funciones que no requieren comunicación inmediata con el servidor. En cuanto a lo que puede hacer la aplicación, no hay diferencia entre ejecutar el navegador o empaquetarla en una PWA, salvo que en esta última el desarrollador tiene más control sobre lo que se almacena localmente.
La representación de interfaces desde HTML es una actividad tan recurrente que el motor suele ser un componente de software independiente, presente en el sistema operativo. Su presencia como componente independiente permite que diferentes aplicaciones lo incorporen sin tener que incrustarlo en el paquete de la aplicación. Este modelo también delega el mantenimiento del motor de renderizado al sistema operativo, facilitando las actualizaciones. Es muy importante mantener actualizado un componente tan crucial para evitar posibles fallas.
Independientemente de su método de entrega, las aplicaciones escritas en HTML se ejecutan en una capa de abstracción creada por el motor, que funciona como un entorno de ejecución aislado. En particular, en el caso de un cliente que se ejecuta en el navegador, la aplicación tiene a su disposición únicamente aquellos recursos que ofrece el navegador. Las funciones básicas, como la interacción con los elementos de la página y la solicitud de archivos a través de HTTP, siempre están disponibles. Los recursos que pueden contener información confidencial, como el acceso a archivos locales, la ubicación geográfica, la cámara y el micrófono, requieren una autorización explícita del usuario antes de que la aplicación pueda usarlos.
Lenguajes de un cliente web
El elemento central de un cliente de aplicación web que se ejecuta en el servidor es el documento HTML. Además de presentar los elementos de la interfaz que muestra el navegador de forma estructurada, el documento HTML contiene las direcciones de todos los archivos necesarios para la correcta presentación y funcionamiento del cliente.
HTML por sí solo no tiene mucha versatilidad para construir interfaces más elaboradas y no tiene características de programación de propósito general. Por esta razón, un documento HTML que debería funcionar como una aplicación cliente siempre va acompañado de uno o más conjuntos de CSS y JavaScript.
El CSS se puede proporcionar como un archivo separado o directamente en el propio archivo HTML. El propósito principal de CSS es ajustar la apariencia y el diseño de los elementos de la interfaz HTML. Aunque no es estrictamente necesario, las interfaces más sofisticadas suelen requerir modificaciones en las propiedades CSS de los elementos para satisfacer sus necesidades.
JavaScript es un componente prácticamente indispensable. Los procedimientos escritos en JavaScript responden a eventos en el navegador. Estos eventos pueden ser causados por el usuario o no interactivos. Sin JavaScript, un documento HTML está prácticamente limitado a texto e imágenes. El uso de JavaScript en documentos HTML le permite ampliar la interactividad más allá de los hipervínculos y formularios, haciendo que el navegador muestre la página como una interfaz de aplicación convencional.
JavaScript es un lenguaje de programación de propósito general, pero su uso principal es en aplicaciones web. Se puede acceder a las características del entorno de ejecución del navegador a través de palabras claves de JavaScript, que se utilizan en un script para realizar la operación deseada. El término document
, por ejemplo, se utiliza en el código JavaScript para hacer referencia al documento HTML asociado con el código JavaScript. En el contexto del lenguaje JavaScript, document
es un objeto global con propiedades y métodos que se pueden usar para obtener información de cualquier elemento en el documento HTML. Más importante aún, puede usar el objeto document
para modificar sus elementos y asociarlos con acciones personalizadas escritas en JavaScript.
Una aplicación cliente basada en tecnologías web es multiplataforma, porque puede ejecutarse en cualquier dispositivo que tenga un navegador web compatible.
Sin embargo, estar confinado al navegador impone limitaciones a las aplicaciones web en comparación con las aplicaciones nativas. La intermediación realizada por el navegador permite una programación de mayor nivel y aumenta la seguridad, pero también aumenta el procesamiento y el consumo de memoria.
Los desarrolladores trabajan continuamente en los navegadores para proporcionar más funciones y mejorar el rendimiento de las aplicaciones JavaScript, pero existen aspectos intrínsecos a la ejecución de scripts como JavaScript que les imponen una desventaja en comparación con los programas nativos para el mismo hardware.
Una característica que mejora significativamente el rendimiento de las aplicaciones JavaScript que se ejecutan en el navegador es WebAssembly. WebAssembly es un tipo de JavaScript compilado que produce código fuente escrito en un lenguaje de bajo nivel más eficiente, como el lenguaje C. WebAssembly puede acelerar principalmente las actividades que requieren un uso intensivo del procesador, ya que evita gran parte de la traducción realizada por el navegador cuando se ejecuta un programa escrito en JavaScript convencional.
Independientemente de los detalles de implementación de la aplicación, todo el código HTML, CSS, JavaScript y archivos multimedia deben obtenerse primero del servidor. El navegador obtiene estos archivos como una página de Internet, es decir, con una dirección a la que accede el navegador.
Una página web que actúa como interfaz para una aplicación web es como un documento HTML simple, pero agrega comportamientos adicionales. En las páginas convencionales, el usuario es dirigido a otra página después de hacer clic en un enlace. Las aplicaciones web pueden presentar su interfaz y responder a los eventos del usuario sin cargar nuevas páginas en la ventana del navegador. La modificación de este comportamiento estándar en páginas HTML se realiza mediante programación JavaScript.
Un cliente de correo web, por ejemplo, muestra mensajes y cambia entre carpetas de mensajes sin salir de la página. Esto es posible porque el cliente usa JavaScript para reaccionar a las acciones del usuario y realizar las solicitudes adecuadas al servidor. Si el usuario hace clic en el asunto de un mensaje en la bandeja de entrada, un código JavaScript asociado con este evento solicita el contenido de ese mensaje del servidor (utilizando la llamada API correspondiente). Tan pronto como el cliente recibe la respuesta, el navegador muestra el mensaje en la parte correspondiente de la misma página. Los diferentes clientes de correo web pueden adoptar diferentes estrategias, pero todos utilizan este mismo principio.
Por tanto, además de proporcionar al navegador los archivos que componen el cliente, el servidor también debe ser capaz de atender solicitudes como la del cliente webmail, cuando solicita el contenido de un mensaje específico. Cada solicitud que puede realizar el cliente tiene un procedimiento predefinido para responder en el servidor, cuya API puede definir diferentes métodos para identificar a qué procedimiento se refiere la solicitud. Los métodos más comunes son:
-
Direcciones, a través de un localizador uniforme de recursos (URL)
-
Campos en el encabezado HTTP
-
Métodos GET/POST
-
WebSockets
Un método puede ser más adecuado que otro, dependiendo del propósito de la solicitud y otros criterios que tenga en cuenta el desarrollador. En general, las aplicaciones web utilizan una combinación de métodos, cada uno en una circunstancia específica.
El paradigma Representational State Transfer (REST) se usa ampliamente para la comunicación en aplicaciones web, porque se basa en los métodos básicos disponibles en HTTP. El encabezado de una solicitud HTTP comienza con una palabra clave que define la operación básica a realizar: GET
, POST
, PUT
, DELETE
, etc., acompañada de la URL correspondiente donde se aplicará la acción. Si la aplicación requiere operaciones más específicas, con una descripción más detallada de la operación solicitada, el protocolo GraphQL puede ser una opción más adecuada.
Las aplicaciones desarrolladas utilizando el modelo cliente/servidor están sujetas a inestabilidades en la comunicación. Por ello, la aplicación cliente siempre debe adoptar estrategias de transferencia de datos eficientes para favorecer su consistencia y no perjudicar la experiencia del usuario.
El lado del servidor
A pesar de ser el actor principal en una aplicación web, el servidor es el lado pasivo de la comunicación, simplemente respondiendo a las solicitudes realizadas por el cliente. En la jerga web, server puede referirse a la máquina que recibe las solicitudes, el programa que maneja específicamente las solicitudes HTTP o la secuencia de comandos del destinatario que produce una respuesta a la solicitud. Esta última definición es la más relevante en el contexto de la arquitectura de aplicaciones web, pero todas están estrechamente relacionadas. Aunque solo están parcialmente dentro del alcance del desarrollador del servidor de aplicaciones, la máquina, el sistema operativo y el servidor HTTP no pueden ignorarse, porque son fundamentales para ejecutar el servidor de aplicaciones y, a menudo, se cruzan.
Manejo de rutas de solicitudes
Los servidores HTTP, como Apache y NGINX, generalmente requieren cambios de configuración específicos para satisfacer las necesidades de la aplicación. De forma predeterminada, los servidores HTTP tradicionales asocian directamente la ruta indicada en la solicitud a un archivo en el sistema de archivos local. Si el servidor HTTP de un sitio web mantiene sus archivos HTML en el directorio /srv/www
, por ejemplo, una solicitud con la ruta /en/about.html
recibirá el contenido del archivo /srv/www/en/about.html
como respuesta, si el archivo existe. Los sitios web más sofisticados, y especialmente las aplicaciones web, exigen tratamientos personalizados para diferentes tipos de solicitudes. En este escenario, parte de la implementación de la aplicación es modificar la configuración del servidor HTTP para cumplir con los requisitos de la aplicación.
Alternativamente, existen marcos que le permiten integrar la gestión de solicitudes HTTP y la implementación del código de la aplicación en un solo lugar, lo que permite al desarrollador centrarse más en el propósito de la aplicación que en los detalles de la plataforma. En Node.js Express, por ejemplo, todos los mapeos de solicitudes y la programación correspondiente se implementan mediante JavaScript. Como la programación de los clientes se realiza habitualmente en JavaScript, muchos desarrolladores consideran una buena idea desde la perspectiva del mantenimiento del código utilizar el mismo lenguaje para cliente y servidor. Otros lenguajes comúnmente utilizados para implementar el lado del servidor, ya sea en marcos o en servidores HTTP tradicionales, son PHP, Python, Ruby, Java y C #.
Sistemas de gestión de bases de datos
Depende del criterio del equipo de desarrollo cómo se almacenan en el servidor los datos recibidos o solicitados por el cliente, pero existen pautas generales que se aplican a la mayoría de los casos. Es conveniente mantener el contenido estático (imágenes, código JavaScript y CSS que no cambian en el corto plazo) como archivos convencionales, ya sea en el propio sistema de archivos del servidor o distribuidos a través de una red de entrega de contenido (CDN). Otros tipos de contenido, como mensajes de correo electrónico en una aplicación de correo web, detalles de productos en una aplicación de compras y registros de transacciones, se almacenan de manera más conveniente en un sistema de administración de base de datos (DBMS).
El tipo más tradicional de sistema de gestión de bases de datos es la base de datos relacional. En él, el diseñador de la aplicación define las tablas de datos y el formato de entrada aceptado por cada tabla. El conjunto de tablas de la base de datos contiene todos los datos dinámicos consumidos y producidos por la aplicación. Una aplicación de compras, por ejemplo, puede tener una tabla que contiene una entrada con los detalles de cada producto en la tienda y una tabla que registra los artículos comprados por un usuario. La tabla de artículos comprados contiene referencias a entradas en la tabla de productos, creando relaciones entre las tablas. Este enfoque puede optimizar el almacenamiento y el acceso a los datos, así como permitir consultas en tablas combinadas utilizando el lenguaje adoptado por el sistema de gestión de la base de datos. El lenguaje de base de datos relacional más popular es el Structured Query Language (SQL, pronunciado “sequel”), adoptado por las bases de datos de código abierto SQLite, MySQL, MariaDB y PostgreSQL.
Una alternativa a las bases de datos relacionales es una forma de base de datos que no requiere una estructura rígida para los datos. Estas bases de datos se denominan bases de datos no relacionales o simplemente NoSQL. Aunque pueden incorporar algunas características similares a las que se encuentran en las bases de datos relacionales, el enfoque está en permitir una mayor flexibilidad en el almacenamiento y acceso a los datos almacenados, pasando la tarea de procesar esos datos a la propia aplicación. MongoDB, CouchDB y Redis son sistemas comunes de administración de bases de datos no relacionales.
Mantenimiento de contenido
Independientemente del modelo de base de datos adoptado, las aplicaciones deben agregar datos y probablemente actualizarlos durante la vida útil de las aplicaciones. En algunas aplicaciones, como el correo web, los propios usuarios proporcionan datos a la base de datos cuando utilizan el cliente para enviar y recibir mensajes. En otros casos, como en la aplicación de compras, es importante permitir que los mantenedores de la aplicación modifiquen la base de datos sin tener que recurrir a la programación. Por lo tanto, muchas organizaciones adoptan algún tipo de sistema de gestión de contenido (CMS), que permite a los usuarios no técnicos administrar la aplicación. Por lo tanto, para la mayoría de las aplicaciones web, es necesario implementar al menos dos tipos de clientes: un cliente no privilegiado, utilizado por usuarios normales, y un cliente privilegiado, utilizado por usuarios especiales para mantener y actualizar la información presentada por la aplicación.
Ejercicios Guiados
-
¿Qué lenguaje de programación se utiliza junto con HTML para crear clientes de aplicaciones web?
-
¿En qué se diferencia la recuperación de una aplicación web de la de una aplicación nativa?
-
¿En qué se diferencia una aplicación web de una aplicación nativa en el acceso al hardware local?
-
Cite una característica de un cliente de aplicación web que lo distinga de una página web normal.
Ejercicios Exploratorios
-
¿Qué característica ofrecen los navegadores modernos para superar el bajo rendimiento de los clientes de aplicaciones web con uso intensivo de CPU?
-
Si una aplicación web usa el paradigma REST para la comunicación cliente/servidor, ¿qué método HTTP debe usarse cuando el cliente solicita al servidor que borre un recurso específico?
-
Cite cinco lenguajes de secuencias de comandos de servidor compatibles con el servidor HTTP Apache.
-
¿Por qué las bases de datos no relacionales se consideran más fáciles de mantener y actualizar que las bases de datos relacionales?
Resumen
Esta lección cubre los conceptos y estándares en tecnología y arquitectura de desarrollo web. El principio es simple: el navegador web ejecuta la aplicación cliente, que se comunica con la aplicación principal que se ejecuta en el servidor. Aunque simples en principio, las aplicaciones web deben combinar muchas tecnologías para adoptar el principio de computación cliente y servidor en la web. La lección abarca los siguientes conceptos:
-
El papel de los navegadores web y los servidores web.
-
Tecnologías y estándares comunes de desarrollo web.
-
Cómo los clientes web pueden comunicarse con el servidor.
-
Tipos de servidores web y bases de datos de servidores.
Respuestas a los ejercicios guiados
-
¿Qué lenguaje de programación se utiliza junto con HTML para crear clientes de aplicaciones web?
JavaScript
-
¿En qué se diferencia la recuperación de una aplicación web de la de una aplicación nativa?
No hay una aplicación web instalada. En cambio, algunas partes se ejecutan en el servidor y la interfaz del cliente se ejecuta en un navegador web normal.
-
¿En qué se diferencia una aplicación web de una aplicación nativa en el acceso al hardware local?
Todo acceso a los recursos locales, como almacenamiento, cámaras o micrófonos, está mediado por el navegador y requiere una autorización explícita del usuario para funcionar.
-
Cite una característica de un cliente de aplicación web que lo distinga de una página web normal.
La interacción con las páginas web tradicionales se limita básicamente a hipervínculos y formularios de envío, mientras que los clientes de aplicaciones web están más cerca de una interfaz de aplicación convencional.
Respuestas a los ejercicios de exploración
-
¿Qué característica ofrecen los navegadores modernos para superar el bajo rendimiento de los clientes de aplicaciones web con uso intensivo de CPU?
Los desarrolladores pueden utilizar WebAssembly para implementar las partes de la aplicación cliente que consumen mucha CPU. El código de WebAssembly generalmente tiene un mejor rendimiento que el JavaScript tradicional, porque requiere menos traducción de instrucciones.
-
Si una aplicación web usa el paradigma REST para la comunicación cliente/servidor, ¿qué método HTTP debe usarse cuando el cliente solicita al servidor que borre un recurso específico?
REST se basa en métodos HTTP estándar, por lo que debería usar el método
DELETE
estándar en este caso. -
Cite cinco lenguajes de secuencias de comandos de servidor compatibles con el servidor HTTP Apache.
PHP, Go, Perl, Python y Ruby.
-
¿Por qué las bases de datos no relacionales se consideran más fáciles de mantener y actualizar que las bases de datos relacionales?
A diferencia de las bases de datos relacionales, las bases de datos no relacionales no requieren que los datos se ajusten a estructuras rígidas predefinidas, lo que facilita la implementación de cambios en las estructuras de datos sin afectar los datos existentes.