Entonces necesito implementar un punto final de API "caro". Básicamente, el usuario/cliente necesitaría poder crear un "grupo" de usuarios existentes.
Por lo tanto, esta API de "creación de grupo" debería verificar que cada usuario cumpla con los criterios, es decir, todos los usuarios en el mismo grupo deberían ser de la misma región, del mismo género, dentro de un grupo de edad, etc. Esta operación puede ser bastante costosa, especialmente porque no hay límite en la cantidad de usuarios en un grupo, por lo que es posible que el cliente solicite un grupo de 1000 usuarios, por ejemplo.
Mi idea es que el punto final solo creará una entrada en la base de datos y marcará el "grupo" como pendiente, mientras el proceso de verificación aún está ocurriendo, luego de que se complete, actualizará el estado del grupo a "completado" o "error" con error mensaje, entonces el cliente necesitaría recuperar periódicamente el estado si todavía está pendiente.
Mi idea de implementación es algo a lo largo de esta línea
const createGroup = async (req, res) => { const { ownerUserId, userIds } = req.body; // This will create database entry of group with "pending" status and return the primary key const groupId = await insertGroup(ownerUserId, 'pending'); // This is an expensive function which will do checking over the network, and would take 0.5s per user id for example // I would like this to keep running after this API endpoint send the response to client checkUser(userIds) .then((isUserIdsValid) => { if (isUserIdsValid) { updateGroup(groupId, 'success'); } else { updateGroup(groupId, 'error'); } }) .catch((err) => { console.error(err); updateGroup(groupId, 'error'); }); // The client will receive a groupId to check periodically whether its ready via separate API res.status(200).json({ groupId }); };Mi pregunta es, ¿es buena idea hacer esto? ¿Me falta algo importante que deba considerar?
Sí, este es el enfoque estándar para las operaciones de larga duración. En lugar de ofrecer una API createGroup que crea y devuelve un grupo, piense que tiene una API addGroupCreationJob que crea y devuelve un trabajo.
En lugar de sondear (obtener periódicamente el estado para verificar si aún está pendiente), puede usar una API de notificación (eventos a través de websocket, SSE, webhooks, etc.) e incluso suscribirse al progreso del procesamiento. Pero claro, una API de verificación de estado (a través de una solicitud GET en el identificador del trabajo) es el mínimo común denominador que todos los tipos de clientes podrán usar.
¿No consideré algo importante?
El manejo de fallas se está volviendo mucho más complicado. Dado que ya no crea el grupo en una sola transacción, es posible que su aplicación se quede en algún estado intermedio, por ejemplo, cuando el servicio falló (debido a cosas no relacionadas) durante la llamada checkUser() . Necesitará algo para asegurarse de que no haya grupos pendientes en su base de datos para los que no se esté ejecutando ningún proceso de creación real. Deberá dar a los usuarios la capacidad de volver a intentar un trabajo. ¿ insertGroup si ya hay un grupo con el mismo identificador en el estado de error ? Si separa el grupo y los trabajos en entidades independientes, ¿necesita asegurarse de que no haya dos trabajos pendientes que intenten crear el mismo grupo? Por último, pero no menos importante, es posible que desee permitir que los usuarios cancelen un trabajo que se está ejecutando actualmente.