Llamadas asíncronas vs síncronas vs cliente-servidor

Clase 27 de 43Curso Profesional de Arquitectura de Software

Contenido del curso

Atributos de calidad

Patrones de arquitectura

Diseño de una arquitectura

Resumen

Entiende con claridad cuándo elegir llamado asíncrono, llamado sincrónico o un conector cliente-servidor. Aquí se explica cómo se comportan, qué implican en la ejecución y por qué se usan en aplicaciones móviles y web modernas, sin teorías extra ni rodeos.

¿Qué es un llamado asíncrono y cuándo usarlo?

Un componente invoca a otro, sabe a quién llama, pero no espera el resultado: continúa trabajando y evalúa la respuesta más tarde. Es común en sistemas desconectados, como una app móvil o una app web tipo React o Angular, que hacen un pedido y lo procesan cuando lo necesitan.

  • El emisor no se bloquea: sigue ejecutando su lógica.
  • Se evalúa el resultado en otro momento.
  • Típico en apps móviles y web con UI reactiva.
  • Útil cuando la disponibilidad de red es variable.

¿Cómo se gestiona la respuesta con promesas o futuros?

Se usan promesas o futuros: estructuras que representan un resultado pendiente y permiten evaluarlo posteriormente. El objetivo es separar la invocación de la consumición del resultado, manteniendo fluidez en la ejecución.

  • Promesas: modelo para registrar la respuesta cuando llegue.
  • Futuros: objeto que encapsula el valor que estará disponible después.

¿Dónde aparece en aplicaciones móviles y web?

En apps móviles y frontends web como React o Angular, se realizan pedidos asíncronos al backend y se procesan al necesitar la información.

  • Ejemplo típico: carga de datos sin bloquear la interfaz.
  • Beneficio clave: mejor experiencia del usuario.

¿Cómo funciona un llamado sincrónico en objetos y procedimientos?

En el llamado sincrónico, el emisor espera la respuesta del receptor y no continúa hasta recibirla. Es el comportamiento natural en lenguajes procedurales y orientados a objetos.

  • El control de ejecución se transfiere al receptor.
  • La ejecución vuelve cuando el receptor termina.
  • Es el modelo por defecto en muchos lenguajes.

¿Qué implica delegar ejecución entre objetos?

Al invocar un método de otro objeto, se delegan la responsabilidad y la ejecución. Hasta que ese método no finaliza, el objeto original no recupera el control.

  • Secuencia clara: invocar, ejecutar, devolver control.
  • Facilita trazabilidad y razonamiento paso a paso.

¿Se puede evitar el bloqueo con hilos?

Sí: algunos lenguajes permiten abrir un hilo separado para evitar el bloqueo. Aun así, el comportamiento natural del modelo sigue siendo sincrónico.

  • Hilos: alternativa controlada al bloqueo.
  • Precaución: añade complejidad en coordinación.

¿Qué define el conector cliente-servidor y cómo resuelve el servidor?

En el conector cliente-servidor hay dos roles: un componente actúa como cliente y otro como servidor. La comunicación va del cliente al servidor y el cliente espera la respuesta. Su foco no es tanto síncrono o asíncrono, sino cómo se distribuyen los componentes.

  • Los componentes pueden vivir en ecosistemas distintos.
  • El cliente puede no conocer de antemano al servidor.
  • Se apoya en protocolos para ubicar el servidor.

¿Cómo ayuda DNS a encontrar el servidor?

En Internet, se usa DNS para resolver un nombre a una o más IP de servidores. Esas IP pueden no ser el destino final: pueden existir capas internas que distribuyen la carga en múltiples servidores.

  • Resolución de nombres a IP.
  • Posibles capas de distribución de carga.
  • Mayor escalabilidad y disponibilidad.

¿Por qué cliente-servidor trata sobre distribución?

Porque enfatiza la separación de roles y la ubicación dinámica del servidor. El cliente puede descubrir el servidor mediante protocolos, y el despliegue puede incluir múltiples niveles para balancear tráfico.

  • Descubrimiento del servidor en tiempo de ejecución.
  • Componentes sin necesidad de convivir en el mismo entorno.

¿Con qué tipo de conector trabajas más y por qué? Comparte tu experiencia y ejemplos en los comentarios.