Arquitecturas de aplicaciones web

Una aplicación ficticia de entradas permite elegir asiento, pagar y recibir un correo. La página presenta una sola actividad, pero cooperan varios componentes. Comprender sus responsabilidades ayuda a ubicar las decisiones de seguridad.

Tres responsabilidades, muchos despliegues

El Front end presenta información y recoge entradas. El Back end toma decisiones de aplicación. La capa de datos almacena o recupera información. Son funciones lógicas útiles, no una ley que obligue a usar tres máquinas.

Páginas generadas por servidor, aplicaciones de una sola página y clientes móviles reparten la presentación de formas distintas. Un servicio pequeño puede combinar aplicación y almacenamiento en un equipo. Otro puede usar colas, cachés, bases administradas y numerosos procesos. Dibuja los flujos reales sin forzar una estructura universal.

Una API define operaciones que otros programas pueden solicitar. HTTP es común en la web, pero API es un concepto más amplio. Un punto de acceso tampoco es público automáticamente por existir.

El cliente ayuda; los servicios aplican reglas

El navegador puede rechazar un formulario vacío o desactivar un asiento vendido. Mejora la experiencia. El servicio debe validar la solicitud, calcular el precio autorizado y decidir si esa cuenta puede reservar o cancelar.

Hay un Límite de confianza donde un componente acepta información o autoridad de otro. Importa entre navegador y servicio, pero también entre servicios, notificaciones de pago y tareas de fondo. Ser «interno» no elimina la necesidad de comprobar qué puede solicitar cada componente.

La página muestra el precio correcto. ¿La compra es segura?

El servicio debe obtener el precio autorizado y verificar disponibilidad al confirmar. Mostrarlo correctamente no demuestra que la transacción final sea válida. Las compras simultáneas también requieren controles de consistencia.

El mismo lenguaje puede tener otra autoridad

JavaScript funciona en navegadores o servidores mediante entornos como Node.js. Importan entorno, identidades, API disponibles y acceso a datos. El servidor debe proteger credenciales de servicio. El navegador también necesita protección: un fallo en un script compartido puede afectar acciones autenticadas de muchos usuarios, no solo de uno.

Algunas plataformas de datos ofrecen deliberadamente API para navegadores. Su seguridad depende de reglas aplicadas por el servicio, identidades limitadas y configuración pública apropiada. Los secretos administrativos no pertenecen al código que descarga el cliente.

Sigue el trabajo después de la solicitud

El proceso de correo puede necesitar destinatario y referencia de reserva, sin credenciales de pago ni acceso irrestricto a la base. Asigna políticas y responsables a colas, cachés y procesos. Define reintentos para evitar que repetir una solicitud duplique un cobro. Continúa con autorización de objetos e identidades de servicios para estudiar esos límites paso a paso.

Sigue una reserva a lo largo del tiempo

A las 10:00, Maya y Leo ven disponible el asiento B4. A las 10:01, Maya confirma primero. A las 10:02, Leo todavía ve el estado anterior. El servicio debe decidir usando disponibilidad autoritativa cuando confirma la operación; una pantalla desactualizada no debe crear otra reserva válida. Transacciones, restricciones u otros controles de concurrencia coordinan ese cambio. La arquitectura debe identificar quién garantiza el resultado.

Si Maya pierde la conexión después de confirmar, el servicio puede haber guardado ya su reserva. Los reintentos deben considerar ese resultado incierto. Un indicador de espera agotado describe la experiencia del cliente; no demuestra que no ocurrió una transacción. Una recuperación adecuada permite conocer el resultado sin crear ciegamente otra operación.

El estado cruza límites

La sesión relaciona solicitudes con un contexto autenticado. La reserva representa la compra persistente. Una cookie puede llevar el identificador de sesión, una base de datos guarda la reserva y una cola mantiene el correo pendiente. Están relacionados, pero tienen vidas y permisos distintos. Terminar la sesión no debería borrar por accidente una compra; borrar la cookie no equivale a eliminar el registro de sesión del servidor.

TLS puede proteger el tramo del navegador al extremo, mientras otra conexión protegida llega al origen. Si un intermediario termina TLS, forma parte de la confianza porque puede ver el contenido descifrado. Protege las conexiones relevantes y sigue aplicando permisos donde se aprueba la acción.

PrediceLa página de reservas utiliza HTTPS y muestra el nombre de Maya. ¿Demuestra que una cancelación solo puede afectar a sus reservas?

No. El canal protegido y la identidad mostrada no establecen autorización sobre objetos. El servicio debe relacionar la sesión vigente, la reserva solicitada y las reglas de cancelación permitidas.

Continúa con del clic a la respuesta y estado, cookies y sesiones para seguir esos mecanismos paso a paso.