De low-code a Python: migrar sin reescribir todo

La discusion aparece siempre en el mismo punto: el flujo funciona, el equipo lo entiende, pero cada semana alguien pasa tres horas esperando que Make termine de recorrer una lista de contactos o que Zapier no corte la ejecucion a mitad de una paginacion. Ahi es cuando alguien dice "pasemos todo a Python" y el resto se imagina seis semanas reescribiendo lo que ya estaba andando. No hace falta llegar a eso.

Lo que proponemos en este hilo es una migracion por capas. La orquestacion visual se queda donde aporta: triggers, ramas simples, notificaciones, formularios, aprobaciones humanas. Eso no se toca porque funciona y porque el equipo no tecnico lo puede leer. Lo que se mueve a codigo es la parte que duele: loops sobre miles de registros, transformaciones de JSON anidado, llamadas a APIs con paginacion por cursor, calculos repetidos que consumen operaciones de la plataforma sin aportar nada.

Donde corta la capa

El criterio practico que usamos en proyectos con pymes peruanas es simple. Si el nodo se ejecuta mas de doscientas veces al dia, si el payload supera los limites del plan o si el error tipico es un timeout del proveedor externo, ese pedazo sale del editor visual. El resto se queda. Un webhook que recibe un formulario no necesita Python. Una funcion que limpia y normaliza ese formulario antes de insertarlo en tres tablas distintas, si.

La funcion Python se expone de vuelta al flujo como un endpoint HTTP. El editor visual la llama igual que llamaria a cualquier API externa: recibe JSON, devuelve JSON. Eso mantiene el grafo legible y permite que quien no programa entienda el recorrido general sin abrir el repositorio.

Versionar y documentar el contrato

Aqui es donde se rompen la mayoria de las migraciones que vemos. El equipo mueve la logica a Python, la despliega, y nadie escribe que campos espera la funcion ni que devuelve cuando algo falla. Tres semanas despues alguien cambia el nombre de un campo en el formulario de entrada y el flujo empieza a producir registros vacios sin lanzar error. El editor visual no se queja porque el endpoint respondio 200.

La solucion no es sofisticada: un archivo de contrato versionado junto al codigo, con ejemplos de payload de entrada y salida, y una validacion al inicio de la funcion que rechace lo que no calza. Si el contrato cambia, cambia la version del endpoint y el flujo visual se actualiza a proposito, no por accidente.

Errores que aparecen en el camino

El mas comun es asumir que el editor visual y el codigo comparten estado. No lo comparten. Si la funcion Python guarda algo en memoria, el siguiente nodo del flujo no lo ve. Todo lo que cruce la frontera tiene que viajar como dato explicito en la respuesta.

El segundo es el manejo de reintentos. La plataforma no-code reintenta a su manera, la funcion Python reintenta a la suya, y sin coordinacion se duplican registros. Conviene decidir quien es responsable de la idempotencia antes de mover la primera linea de codigo.

El tercero es el mas silencioso: el equipo deja de mirar los logs del editor visual porque "eso ya es solo orquestacion". Pero ahi siguen viviendo los triggers y las notificaciones, y ahi siguen apareciendo los fallos que nadie revisa. La capa visual no es menos importante por ser visual.

Si estas armando esta transicion y quieres contrastar como lo resolvieron otros equipos, en el hilo sobre webhooks que no se caen a las 3 AM hay patrones de reintento que aplican directo a este escenario. Y si el cuello de botella esta mas en el lado de los datos que en el de la logica, vale la pena revisar las soluciones que la comunidad viene probando antes de decidir que mover primero.