Networking + Interfaces gráficas (frontend-backend)
Cómo integrar la arquitectura cliente-servidor con una interfaz gráfica: dónde viven los sockets, servidor como función vs como clase, y la flexibilidad de QThread o threading.
hub
Mezclar networking y GUI
Ya vimos por separado la arquitectura cliente-servidor (_networking_) y el modelo front-end / back-end de las interfaces. ¿Cómo los combinamos en un mismo proyecto?
Primero, una observación clave: en la mayoría de los casos el servidor no necesita interfaz gráfica, porque su rol es procesar solicitudes, no interactuar directamente con un usuario. Por lo tanto, suele ser solo el cliente quien tiene interfaz. (Pueden existir excepciones, como un servidor con una GUI para monitorear su consumo de recursos).
Segundo: como el _networking_ se trata de comunicación entre programas, todo lo que cree y use _sockets_ es parte del _back-end_ del cliente (son controladores de la interfaz). El esquema típico ubica los sockets en el back, y la ventana en el front.
Idea central: los sockets viven en el back-end del cliente. La interfaz (front-end) nunca habla directamente con la red; lo hace a través del controlador lógico del back.
Nota
Cargando Quiz...
code
Servidor como función
El primer ejemplo (1_ejemplo_simple) es básico: la interfaz pide información sobre una palabra o un color al servidor, y este responde con un valor aleatorio de esa categoría, que se muestra en la ventana.
El detalle importante: en el controlador del _back-end_ se levanta un hilo dedicado exclusivamente a escuchar los mensajes del servidor y transmitirlos al controlador. Así la interfaz puede seguir haciendo otras cosas en vez de quedarse "pegada" esperando respuesta.
python
# En el back-end del cliente: un hilo solo para escuchar al servidorclass EscuchaServidor(QThread): senal_respuesta = pyqtSignal(str) def run(self) -> None: while True: datos = self.socket.recv(BUFFER) mensaje = datos.decode() self.senal_respuesta.emit(mensaje) # avisa al controladorPara la comunicación, en este ejemplo el cliente codifica y envía un _string_, y el servidor responde con otro _string_ codificado.
Cargando Quiz...
schema
Servidor como clase
El segundo ejemplo (2_ejemplo_avanzado) es más completo: el servidor actúa como puente entre los clientes. Al conectarse, un cliente pide al servidor la hora de Chile (o puede pedir la de Japón).
La diferencia clave: el cliente también puede pedir adelantar o retrasar el tiempo en 1 hora, y esa solicitud afecta a todos los clientes conectados. Si uno adelanta la hora, todos ven cómo su reloj se adelanta. Por eso conviene probarlo con al menos 2 clientes.
Aquí la comunicación es más estructurada: el cliente codifica y envía un diccionario con dos elementos:
"key": el comando a realizar (pedir la hora de un país, o cambiar el tiempo)."arg": el argumento del comando (el país —chile o japón—, o hacia dónde mover el tiempo).
python
# El cliente envia un diccionario codificadomensaje = {'key': 'hora', 'arg': 'chile'}socket.send(json.dumps(mensaje).encode()) # Otro ejemplo: cambiar el tiempo para TODOS los clientesmensaje = {'key': 'cambiar', 'arg': 'adelantar'}info
Acotación: QThread o threading
Para ambos ejemplos se publicaron dos versiones del back-end del cliente: una hecha con QThread y otra con threading. Por defecto se usa QThread.
Para cambiar de una a otra basta con actualizar una sola línea del main.py (la del import del backend). Gracias a una correcta modelación, el _front-end_ no necesita cambios.
python
# main.py del cliente -> basta cambiar el import del backendfrom backend.backend_qthread import Backend # version con QThread (por defecto)# from backend.backend_thread import Backend # version con threadingCon threading o con QThread se logra el mismo resultado, así que queda a criterio de cada quien cuál usar. Es, de nuevo, un ejemplo de que una buena modelación permite cambiar 1 archivo y que el programa siga funcionando.
Cargando Quiz...