Django Asíncrono: Desbloqueando el Poder de la Programación Async - Luis Martinez

Speaker 1: Hola , como están? Bueno? ¿Van a ficar? ¿Van a salir? Bueno, bienvenidos a todos. Um ahora applausos para I I don't have your name Luis Martinez conjungo asynchronous Desbloqueando la teleprogramación Async. Por favor, aplausos.

Speaker 2: Bueno, hola. ¿Cómo están? ¿Cansados? Bueno, yo vengo a hablar de Django, porque a mí me gusta, es un framework que me gusta mucho, entonces pues quiero antes de hablar de Django expresar. . parte del conocimiento que tengo también de la programación asíncrona. Pero para poder explicar la programación asíncrona, me quiero devolver un poco a explicar cómo funciona la programación síncrona. Entonces, vamos a empezar y voy a contar una historia acerca de un restaurante donde Hay un mesero, ¿ya? Este mesero atiende una mesa, llega hasta la mesa y te pide, la persona te pide un plato. Llega hasta el restaurante y le dice al chef, prepárame este plato.

Speaker 2: Pero ese mesero se queda esperando que el chef termine de preparar el plato para poder llevarlo a la mesa. Ese tiempo que se quedó esperando ahí es porque es síncrono, o sea, no puede hacer nada más mientras está esperando. Esto pues no es tan óptimo. Esperar en este contexto es como, pues al final, pérdida de tiempo, porque si el mesero podría estar haciendo otra cosa, limpiando o haciendo, sería más útil. Así es como funciona el código de Python in this moment. Cuando tú haces un código que escribes para obtener algo de una API, para obtener algo de una base de datos, para escribir un archivo. El código de Python se queda esperando ahí hasta que termine de escribirlo.

Speaker 2: Entonces, para el caso del. . del restaurante, pues lo que tuvimos o los problemas que tenemos son que tenemos una lentitud acumulada. Imagínense que lleguen tres mesas y el mesero todavía está esperando que le entreguen el primer plato. Posibles bloqueos. Imaginemos que pasa algo en la cocina, se acabó el gas o se acabó algo y les tocó esperar hasta que solucionen ese problema para poder seguir. In Python is so if an API cae and your code is sparing a response and no need a timeout, I see the application ejecut responda. Y poca escalabilidad. ¿Cómo solucionamos la escalabilidad en el restaurante? Contratando otro chef Y otro

Speaker 2: mesero, porque pues es como lo ideal. Entonces, acá es donde estamos entendiendo el bloqueante. El bloqueante es los inputs y los outputs. Mientras el chef no nos entregue el plato, estamos bloqueados. Mientras el cliente no nos diga la orden que quiere obtener, estamos bloqueados. Mientras en Python estemos tratando de hacer cualquier acción externa que implique input o output. Estamos bloqueados en el código. Entonces, hasta acá es que ya empezamos a pensar en qué soluciones hay. Si lo pensamos en el restaurante, la solución es. Conseguir que este mesero no se quede esperando al chef que termine el plato, que en vez de este caso

Speaker 2: vaya y siga atendiendo otras mesas o siga haciendo otras acciones. Es decir, quitarle esa pausa que está ahí teniendo. En Python nosotros tenemos el módulo Async. io. Este módulo nos permite a nosotros decirle al código, hey, aquí hay una acción, que esta acción es de input o de output. Aquí vas a poder decir como hey, ve a hacer otra cosa. ¿Esto cómo lo hacemos? Es básicamente definir con Python una lista de tareas que se van a estar ejecutando paralelamente. dentro de nuestro servidor sin necesidad de que esperemos una respuesta. ¿Cuáles son las las. ventajas

Speaker 2: que vamos a tener, que vamos a tener más peticiones simultáneas. Si lo vemos desde el punto del restaurante, igual. Mientras el. mesero no está esperando que hagan el plato, podría estar tomando más peticiones, vamos a reducir los tiempos de espera, porque entonces si hay dos mesas, tres mesas, el chef ya podría estar también trabajando en varios platos al mismo tiempo. Y escalabilidad. Ya no necesitamos un nuevo mesero para atender tres mesas. En el caso de Python no necesitaríamos otro servidor, no necesitaríamos otro hilo que se esté ejecutando en nuestro servidor para hacer esto útil. Entonces, en Async. io nosotros tenemos algo que se llama 11 loop, que es como les comenté.

Speaker 2: Nosotros tenemos un stack de tareas. Y hay un loop que literalmente está revisando esa lista de tareas para ver si hay una nueva o para ver si se completó una tarea. Si hay una nueva que no se está ejecutando, la manda a ejecutar. Si hay una que ya se completó, retorna el valor al que sea que esté esperando la respuesta. Y esto indefinidamente, por eso el task n. Ahora, en una aplicación web, esto es un poco diferente. En las aplicaciones web, por ejemplo, en Django utilizamos algo que se llama. . W SGI que es cómo ejecutar código de Python en un servidor web de manera síncrona.

Speaker 2: Para poder correr un Event Loop dentro de Django o un servidor web tenemos que utilizar algo como Daphne o como Ubicorn. que Ubicorn es por ejemplo una de los de las librerías que utiliza Sebastián de Fast API para correr su framework. Luego venimos también con lo básico. Vamos a aprender a hacer código asíncrono dentro de Python. Entonces hay dos palabras mágicas que hay que aprender. The prime is the async and the second is the law. Definir que una tarea puede tener una pausa dentro. Entonces, definimos una función, por ejemplo, podría ser asyncTarea.

Speaker 2: Y adentro podríamos ya utilizar el await diciéndole, hey, esto podría demorarse, entonces mándalo a ejecutar y mientras no tenga respuesta, pues puedes ir haciendo otra cosa. Vamos a verlo en ejemplo. Entonces aquí tenemos esta tarea que es fácil, es de saludar. Si lo vemos, solamente está simulando que está esperando por algo, le pusimos un slip de uno. Y un saludo, retorna un string que dice hola PyCon, usa. Esto funciona bien si fuera una sola persona. Recuerden que entonces, como es síncrono, si va a saludar a 100 personas, pues entonces va a esperar. 100 segundos y a la persona número 100 la va a saludar 100 segundos después. Para mejorar esto vamos a convertirla a Sing.

Speaker 2: Como ya vimos, se debe convertir utilizando las dos palabras mágicas. ¿Dónde aparecen? En la línea 3 utilizamos el async para decirle, hey, saludar puede tener algo que se puede demorar. Y en la línea 5 utilizamos el await para decirle al Even Loop, hey, toma esta tarea para que la ejecutes, mientras yo estoy haciendo otra cosa. Algo muy importante también cambió acá y es la línea 1. Si notan, hay un nuevo módulo que estamos importando que es Async IO. En el slide anterior lo estábamos haciendo desde Time. Como todas las funciones deben tener para poder ser asíncronas, deben tener esta palabra async para poder usar el await.

Speaker 2: Nos tocó también cambiar el timer por una que sí utilice ese async. Si nos vamos a la definición de ese slip, es una función asíncrona que podemos utilizar. Entonces, todo este cuento, ¿por qué? Ya sabemos lo básico de la programación asíncrona, pero ¿qué pasa con Django? Las charlas de Django, ¿no? Y básicamente es. Yo fui a la PyCon de Medellín el año pasado y me puse a hablar con este señor, que él es Sebastián Ramírez, que él creó Fast API. Y pues a mí me gusta Django. Entonces yo llegué con la pregunta jocosa de ¿qué pensás de Django?

Speaker 2: Pues porque él creó Fasta API y mucha gente lo usa y de hecho hay muchos posts donde comparan a Django con Fasta API. Entonces él se quedó pensando y pensó que lo estaba como molestando. Entonces le repetí que pensás de Django, serio. And Django es un framework muy usado, lo usan muchas empresas, por ejemplo, lo usa Instagram, lo usa Netflix. Pero cuando fue creado, la versión de Python no soportaba asincronismo. Entonces, mucho código que está escrito en Django ni siquiera soporta todavía el asincronismo. Entonces ahí nació esta charla, porque yo dije, ¿cómo así que no?

Speaker 2: Vamos a ver por qué. Y efectivamente me metí al código fuente de Django y mucho código no soporta sincronismo. Pero habían muchos planes de empezar a hacerlo. Entonces, por acá voy a empezar a mostrarles cómo Django empezó a implementar el asincronismo dentro. de su framework. Empezaron a utilizar nuevas librerías, un nuevo archivo OPG que vamos a ver y una nueva app. Entonces , De las librerías. Fíjense cómo la primera línea es un ASGI. Recuerden que para poder ejecutar aplicaciones web, nosotros asíncronamente necesitamos el ASGI Ref. Con esto que estamos

Speaker 2: implementando en esta aplicación, el Event Loop. O sea, vamos a poder utilizar este Event Loop que antes no podíamos utilizar. Esta es una instalación de Django hoy en día. Justo revisé que esas fueran las mismas versiones y estas son las tres librerías que utiliza para volverse asíncrono. Tenemos nuevos archivos. En las versiones anteriores solo teníamos este WSGI, que recuerden, es el de código síncrono. Y ahora tenemos el asgi. pg. Un dato para tener en cuenta acá es que el código de WSGI sí se puede ejecutar en el de ASGI, pero al revés no. Entonces hay que tener en cuenta esto.

Speaker 2: Cuando estemos ejecutando, si queremos que nuestra aplicación utilice el asincronismo, asegurarnos que estamos utilizando el ASGI. Luego vamos a ver el archivo internamente porque aquí hay cosas bastante chéveres. La primera en la línea 12. Un nuevo módulo que se llama SGI, que nos permite obtener la aplicación. Esta es la aplicación que al final le vamos a pasar a cualquier servidor. Y la estamos creando acá o automáticamente Django la crea por nosotros mostrándonos, hey, ya con esta aplicación podrías utilizar todos los beneficios que trae utilizar código asíncrono. In history and Django, how

Speaker 2: implementando todo esto? Todo empezó en la versión 3. 0, donde empezaron a decir, hey, ¿qué vamos a hacer? Django recuerden que va en la versión 5. 2, como lo vimos in los requerimientos. In diciembre agregaron lo que les mostré de ASGI, que fue el inicio, como todo el código síncrono podía correr en el código asíncrono, entonces simplemente empezaron por esa tarea. Luego en agosto del 2020 agregaron que ya se podía poner en las vistas de Django, que son las que se encargan de procesar los requests. la palabra sync. Antes no se podía. Si lo colocábamos salía un error y decía que no, que está retornando una corrutina y Django espera un response. Little are aggregators.

Speaker 2: Pero aún no han terminado de crear todo ese código en código asíncrono. Entonces, si en tu aplicación vas a empezar a utilizar. . Este código asíncrono, te recomiendo que vayas a la documentación de Django para revisar si lo que quieres hacer ya se puede hacer asíncronamente. Si no se puede, hay algunas opciones que vamos a ver en el futuro. Entonces acá empecemos viendo el ORM y cómo Django ha ido integrando. Entonces, como ustedes recuerdan, tenemos que agregarle la palabra sync a todos los métodos. Pero Django no iba a hacer eso, iba a volver todo el código asíncrono porque resulta que nosotros usamos Django desde hace mucho tiempo y puede haber muchas aplicaciones que todavía se estén ejecutando síncronamente.

Speaker 2: Entonces, para cambiar eso, lo que ellos hicieron fue inventarse el prefijo A. El prefijo A a casi todos los métodos que están en el ORM. Entonces podemos hacer una GET, una create, todas estas cosas las podemos hacer y ya ese sería código síncrono, o sea, lo podríamos utilizar de esta manera. En el síncrono normal siempre creábamos un filtro, buscábamos todos los libros de Gabo y encontrábamos el primero utilizando la definición del query set. first. Y en la parte de abajo que es asíncrona estamos utilizando lo mismo, solo que ya podemos utilizar el await aquí y debemos poner el A acá. Si no lo ponemos, no va a ser código asíncrono y va a fallar.

Speaker 2: Para las listas, por ejemplo, si ustedes vieron aquí, el filter no tiene A al comienzo. ¿Esto por qué pasa? Porque los filters retornan un query set, no ejecutan nada, solamente retorna algo que probablemente después se va a ejecutar. Entonces, lo que hicieron para estos casos fue agregar la posibilidad de hacer async for El filtro ya retorna el valor que se puede usar asíncronamente y este filtro si lo tenemos en varias partes de nuestro código solamente se va a ejecutar cuando lo vayamos a utilizar una sola vez. Ahora vamos a ver las limitaciones. Estas cosas que tenemos hasta aquí es lo básico y se puede utilizar en todas las aplicaciones, funciona bastante bien, lo he utilizado en entornos productivos.

Speaker 2: Pero hay unas cositas que todavía no funcionan. Entonces, vamos a empezar por lo que no funciona, las transacciones. Las transacciones es un código que nos permite a nosotros ejecutar bastantes, digamos, una lista de inserts o una lista de cambios dentro de nuestra base de datos. que luego si alguna llega a fallar podríamos revertir. Entonces la idea es, falla algo por. Falla algo porque la base de datos falló, entonces devolvemos todas las transacciones que ya habían funcionado. ¿Por qué no funcionan? Porque cuando colocamos este async with transaction atomic dentro de esta vista que es asíncrona, nos retorna este error.

Speaker 2: Nos dice, es una operación síncrona y nosotros estamos en un entorno o en un contexto que es asíncrono. entonces no lo puedes ejecutar. Sin embargo, el error nos muestra algo importante. Nos dice, use un hilo o use un sync to assign. Entonces vamos a usar ese SynctoAsign, en este caso de esta manera. Lo que nos permite este Sync2Asign es coger código síncrono. encapsularlo en un método, ejecutarlo en un hilo y cuando el hilo termine la respuesta, obtener la respuesta. Entonces, utilizando esta metodología, el mismo que ya veníamos utilizando previamente, ya le podemos hacer

Speaker 2: la transacción aquí. Este no tiene el async, pero estamos utilizando el decorador que lo va a volver a sync y acá abajo ya podemos utilizar este que está acá arriba como si fuera asíncrono. ¿Para qué nos sirve? En el código fuente que ustedes estén utilizando de Django, probablemente hay mucho código que no van a poder utilizar todavía asíncronamente. Pero esto es una opción de empezar a hacer como la transformación. Iba a decir actualización, pero no es una actualización. Al final es un cambio de paradigma que estamos. haciendo porque el código va a ser casi que totalmente el mismo. Pero hay una desventaja de utilizar ese SynctoAssign.

Speaker 2: Como lo dije en la descripción, este crea un nuevo hilo. Para el ejemplo del restaurante es como si cogiéramos un cliente que no podemos atender y lo mandamos para otra sede del restaurante que esté vacía. Cuando la CD lo atienda, que vuelva y nos pague. Entonces no tiene sentido que estemos creando más hilos dentro de nuestra aplicación cuando lo que queremos hacer es asincronismo. Entonces vamos a irnos ahora, ya después de ver esa limitante, a crear una view de Django o a crear una URL. Yo tengo este ejemplo que básicamente lo que está haciendo es traer el clima de dos ciudades importantes, Londres y Tokio.

Speaker 2: En la línea 10 y en la 11 estoy haciendo los dos requests. Ahora podemos imaginar eso en código de producción como un request a la API de Tuilio y otro request a la API de Mailgun y otro request otras APIs en este caso es el clima y la quiero convertir a un Asíncrona para que en este caso estos dos requests se hagan al mismo tiempo y no espere que la línea 10 termine para poder ejecutar la línea 11. Eso lo hacemos de esta manera. Entonces, hay un cambio importante. Cambié la librería de request a HTTPX. Fíjense, acá estoy usando request y acá HTTPX. La razón

Speaker 2: request no es asíncrono, o por lo menos no esa versión que estoy utilizando. Y en esta versión estoy utilizando httpx que es. for a request a APIs de manera asyncrone. Y acá le cambio, le coloco el async para volver esta vista asíncrona ando las dos ejecutions. Aquí pueden tomar estas dos líneas como si fueran dos clientes en dos mesas diferentes en el restaurante que hicieron los dos pedidos. Y en este caso, pues no va a esperar que el chef termine, sino que simplemente se va a ir a ejecutar esta otra línea, pero en el caso de acá sí va a esperar que termine, hasta que esta no termine no va a atender esta.

Speaker 2: Entonces, pues vamos a ver el código real y corriendo y hacerle unas pruebas para ver cuánto se demora. Entonces, aquí es donde hago esta cara. Entonces vamos a ver el código. Esta es la aplicación que estoy utilizando para hacer las pruebas. Va a ser una explicación aquí corta de. . de la aplicación acá estamos usando las urls entonces tenemos se alcanza a ver bien Tenemos esta que es un endpoint para hacerlo síncrono y este para hacerlo asíncrono. ¿Cierto? En las vistas

Speaker 2: está igual, tal cual como lo acabamos de ver en la presentación. Aquí estamos viendo Londres, Tokio y acá también. Entonces ejecutemos. ¿Este será que funciona? Hola, hola, hola. Entonces aquí vamos a utilizar la herramienta favorita mía para hacer pruebas de rendimiento que se llama Google Chrome. Entonces vamos a abrir. Ah, bueno, tengo que deshabilitar esto que lo puse ahora.

Speaker 2: Eyeto La de síncrona me devuelve mis dos ubicaciones, Londres y Tokio. Aquí está el tiempo, ciento treinta y dos, y vamos a ejecutar La versión asíncrona, que también me devuelve lo mismo, y 132. Casi que lo mismo en estos dos casos, pero este cuando lo recargo, pues empieza a bajar un poco. En las dos tenemos solo Londres. Vamos al código e intentemos agregar más ciudades. Entonces yo tengo aquí este rever

Speaker 2: para hacer. Y aquí agrego nuevas URLs. Entonces agrego Pittsburgh. Este solamente lo que hace es obtenerme la URL acá. con el API key y una url basado en los datos que le estoy pasando por ejemplo pues aquí paso pues la query Y acá con estas URLs ahorro tiempo para escribir todo esto para hacer el demo. Entonces tenemos. todas las ciudades que quiero poner en ambos ya agregué Pittsburgh Ecuador Chile y Colombia entonces al recargar la versión síncrona Se demoró 800 microsegundos y al recargar la versión asíncrona

Speaker 2: solo subió la mitad. Igual y la API se demora en responder más porque estamos haciendo más requests y el internet aquí probablemente nos está jugando en contra, pero no es más. Si agregamos muchas más queries en la versión síncrona, pues vamos a agregar tiempo en la ejecución de esta vista que nos va a hacer que la aplicación se note lenta cuando en realidad es simplemente que estamos haciendo request más request en este momento Entonces acá ese código de ejemplo yo lo puse in este repositorio. Ahí lo pueden ver andar ajuste or cambio, ahí también su pull request. Y cualquier cosa, pues, ¿no?

Speaker 2: Me cuentan. Ahí me pueden también encontrar en. . . en Platzi, yo doy cursos en Platzi, he dado seis cursos, entonces está el curso de Django, hay un curso de Unit Testing. varios cursos, cualquier estudiante que quiera por lo menos aprender alguna cosa que tenga relación con Python me cuenta. Y esa es esa es la presentación. Preguntas

Speaker 1: No hay preguntas, no creo, no? Una? Bueno. No.

Speaker 3: Ah, es respecto al ORM. Yo también en una charla que tuve con. Sebastián, era acerca de, aun cuando ya se está haciendo la interfaz asíncrona del ORM en Django, me decía que tal vez no era, yo le decía por qué no usas el ORM de Django, si ya está. me decía que uno de los problemas que veía es que hasta donde se había quedado la forma de comunicar. las consultas a del ORM eran mediante TRED Locals y bueno en su eh, el SQL model que está haciendo su RM, usa context bars. Entonces, yo la verdad es que ahí ya no me metí. ¿Tu sabes si en esta interfaz del ORM se está trabajando con Context

Speaker 3: Bars o se usa todavía thread locals? La implementación asíncrona.

Speaker 2: Bueno, es una buena pregunta Y está muy relacionado con las limitantes que todavía tiene el ORM de Django y se basa, por ejemplo, en el ORM de Django está compatible con muchas bases de datos que ni siquiera soportan asincronismo. Entonces Django ahí le toca hacer muy como que compatibilidad de patrás se limita mucho en hacer cambios por ese mismo problema. Entonces, es verdad. lo que dice es verdad no lo pueden cambiar todavía a menos de que en nuevas versiones rompan las versiones pasadas Sí se están haciendo muchos cambios para poder usar el context, pero no creo que vaya a ser muy pronto.

Speaker 4: Puedes hacer el ejemplo otra vez. This

Speaker 2: is I see

Speaker 4: no de en el Chrome. En el browser. Sí , ah los dos URLs son los mismos, ¿no?

Speaker 2: Ah sí.

Speaker 4: Sí , eh esto es lo que me confunde de el ejemplo , podemos

Speaker 2: Sí , mira, este se demoraba trescientos ochenta y este doscientos veinte. Sino que este tiene la A.

Speaker 4: Yo yo creo que en el ejemplo, los yo sé mucho español, entonces disculpa. Pero en el ejemplo, eso , todos los recuerdos que tú tienes ahí no se corren al mismo tiempo. Todavía con el async todavía se tiene que esperar para cada uno porque. uh to tienes el await cuando tú pones el await va a parar hasta que se acaba entonces tú puedes tratarlo puedes poner un print por cada uno y tú vas a ver que no se completa todo lo mismo Tiene que parar para el último para que haga el próximo.

Speaker 2: Sí, o sea, parece que tocará parar, pero realmente él manda a ejecutar las tareas. O sea, poco a poco. ¿Me entiendes? ¿Cómo explico acá? O sea, sería el tema es que es consecuente, a pesar de que en el ejemplo del restaurante sería como a pesar de que vaya y mande todas las órdenes al chef. de todas las mesas el chef no te va a devolver todas al mismo tiempo porque no puede porque solamente va a procesar una sola cosa Como en este ejemplo estoy usando un solo hilo, realmente tiene que esperar. La diferencia está en que se empieza a ejecutar desde antes. Lo que creo que está diciendo ahí es que. La forma en la que estructuraste el ejemplo, cuando tú encolas la primera tarea

Speaker 2: como tiene la web, no va a subir la tarea del stack de la tarea. Porque también lo, bueno, también eso es eso es verdad y lo que podríamos hacer es acausar un gather.

Speaker 4: Sí, sí, es lo que tiene que ver.

Speaker 2: Sí. Sí, lo que pasa es que igual con el event loop que estoy utilizando acá, él va a coger esas tareas y las va a usar, o sea, las va a encolar. Por eso es que te digo eso, que es como si fuera igual la orden llegando a un chef y pues no te las va a atender todas de una.

Speaker 1: Porque si no hablas acá en la grabación, no puede sí

Speaker 5: Porque, bueno, se vio en el ejemplo que hubo una disminución del tiempo, o sea que sí está haciendo algo, porque cuando haces un await Él no necesariamente se para esperar, él crea un punto de espera que le dice a Libelou: Ok, B sigue haciendo otras tareas, pero tú tienes que volver aquí a retornar a buscar el valor. Y esa es la diferencia en porque el law realmente no es que me paro y cuando recibo el valor hago el otro. Yo me paro, creo un punto de espera, veo, tengo más tareas. Sí. Mando a ejecutar esa tarea, llegó al punto de espera, ya la primera finalizó, entonces yo sigo tomando el valor. Y todo eso es la comunicación entre el código y el libre loop.

Speaker 2: y la otra ventaja ahí es plus que si tiene muchos más requests al mis a este endpoint me refiero a este si tiene muchos más requests pues todas esas tareas nuevas también van a estar en el en el en la lista y no va a ser como esperar que se retorne la primera si tuviera un solo núcleo respondiendo ese es el punto Igual y si tienes su punto lo podemos evaluar. Estoy abierto a eso, porque te veo la cara de. .

Speaker 4: Sí, no, me quedo la conclusión que eres. in javascript si tú haces lo que es correcto porque tú vas a weight va a hacer un punto de parar y va a ser otra cosa que está se está corriendo pero Eventualmente va a regresar. In JavaScript la manera como tu arreglar eso is promise. ong. No sé si tu y entonces yo no yo soy nuevo al python entonces yo no sé si la idea es la misma que tú tienes que estar algo de gather entonces esa es la idea que porque Cuando tú haces un await, va a parar ahí y ya cuando se termina eso, es cuando regresa a la execution de la función.

Speaker 2: Sí, el Gather lo que es es el promise. all.

Speaker 4: Sí. Ok.

Speaker 2: Sí, eso explicando Python con JavaScript.

Speaker 1: Well no, this is the end. I know, I'm so sorry. Thank you so much. Thank you, thank you, thank you, please. Yes. And if you do have more questions, please do just chase him out. Okay, thank you very much.