En esta entrada vamos a tratar un aspecto poco conocido del lenguaje que más base de usuarios tiene: Javascript. Todo desarrollador web que se precie conoce de la existencia de este lenguaje que se ejecuta en el cliente y que tiene una curva de aprendizaje muy grande, pero que tiene tantas funcionalidades que es fácil dejar pasar alguna por alto. En nuestro caso, vamos a explicar cómo realizar comunicaciones síncronas.
En definitiva, la idea era realizar peticiones asíncronas, o lo que es igual, el cliente realizaba una petición y seguí funcionando tal cual, hasta que el servidor la procesaba y contestaba, en cuyo caso, el cliente ejecutaba una retrollamada o callback. Básicamente lo que se describe en este gráfico:
Ahora bien, qué ocurre cuando tenemos una web que desde el momento de su carga depende de ciertos datos que se han de extraer del servidor, por ejemplo, supongamos que vamos a hacer una aplicación Ajax que depende de una API JSON y que nuestra aplicación necesita saber unos parámetros antes siquiera de renderizar la web. Es decir, queremos que ocurra lo que se detalla en este gráfico:
$.ajax({
url: "test.php",
type: "GET",
success: function(){
// Se ejecuta cuando se ha recibido correctamente
// los datos de la url
},
error: function(){
// Se ejecuta cuando es imposible obtener
// los datos de la url
},
async: false, // La petición es síncrona
cache: false // No queremos usar la caché del navegador
});
$.ajaxSetup({
async: false
});
// Llamada por GET síncrona
$.get(url, function(data){
});
// Llamada por POST síncrona
$.post(url, function(data){
});
// Volvemos a dejar las llamadas AJAX síncronas
$.ajaxSetup({
async: true
});
Vamos a comenzar con un poco de historia. Con el advenimiento de la web 2.0, se implementaron las peticiones Ajax en este lenguaje, permitiendo realizar cómputo sólo cuando se devolviesen los datos del servidor. Es decir, se dotó al lenguaje de herramientas de comunicación asíncronas, ya que no se obligaba al cliente a esperar que un cómputo del servidor terminase para continuar trabajando en la web. Algo más tarde, con el desarrollo de frameworks de trabajo, se popularizaron todavía más las aplicaciones Ajax, ya que era realmente sencillo que el cliente obtuviera información del servidor sin “abusar de la paciencia del usuario”.
En definitiva, la idea era realizar peticiones asíncronas, o lo que es igual, el cliente realizaba una petición y seguí funcionando tal cual, hasta que el servidor la procesaba y contestaba, en cuyo caso, el cliente ejecutaba una retrollamada o callback. Básicamente lo que se describe en este gráfico:
Ahora bien, qué ocurre cuando tenemos una web que desde el momento de su carga depende de ciertos datos que se han de extraer del servidor, por ejemplo, supongamos que vamos a hacer una aplicación Ajax que depende de una API JSON y que nuestra aplicación necesita saber unos parámetros antes siquiera de renderizar la web. Es decir, queremos que ocurra lo que se detalla en este gráfico:
Para implementar este enfoque podemos usar peticiones síncronas desde jquery, que como vemos en el gráfico hacen que el navegador espere al servidor. La sintaxis $.ajax de jquery (http://api.jquery.com/jQuery.ajax/) nos proporciona una forma sencilla de hacerlas:
$.ajax({
url: "test.php",
type: "GET",
success: function(){
// Se ejecuta cuando se ha recibido correctamente
// los datos de la url
},
error: function(){
// Se ejecuta cuando es imposible obtener
// los datos de la url
},
async: false, // La petición es síncrona
cache: false // No queremos usar la caché del navegador
});
Hay otra forma de realizar peticiones usando los métodos $.get y $.post de forma síncrona que consiste en cambiar los parámetros del objeto AJAX usando la función de configuración ajaxSetup. Así, si queremos realizar dos peticiones síncronas (una GET y otra POST), podemos hacerlo de la siguiente forma:
$.ajaxSetup({
async: false
});
// Llamada por GET síncrona
$.get(url, function(data){
});
// Llamada por POST síncrona
$.post(url, function(data){
});
// Volvemos a dejar las llamadas AJAX síncronas
$.ajaxSetup({
async: true
});
Hay multitud de usos de esta funcionalidad, por ejemplo, si no queremos implementar un protocolo de comunicación, podemos usarlo en una pantalla de buscador (y así nos evitamos que haya una condición de carrera y se muestren resultados de una consulta anterior), o queremos impedir que el usuario realice otra acción hasta que se devuelva una respuesta de su petición, etc.
Por lo general, es mejor evitar las peticiones síncronas debido a que el navegador se bloquea y si el servidor es lento o la conexión tiene problemas, el tiempo de bloqueo puede ser un rato largo. Así que úsese esta herramienta con moderación.
Diego J. Romero
Diego J. Romero
me gusta mucho la explicación, pero desearía ver un ejemplo mas completo del funcionamiento sincrono. muchas gracias
ResponderEliminarMuy buen post, me gustaría que pudieras explicar como manejar estas peticiones cuando van con parametros, ejemplo index?=algo&algo
ResponderEliminarEste comentario ha sido eliminado por un administrador del blog.
EliminarAsi envias todo el formulario
ResponderEliminar$.post(url,
$("#form").serialize(), // Enviando los parametros formato url
function (response) {
});
O asi envias un parametro especifico
$.post(url, {
id: dato
},
function(data) {
});
Excelente, muchas gracias el uso de async: true me fue vital para un proceso con primefaces
ResponderEliminarMUCHAS GRACIAS por la aclaración.
ResponderEliminarMuy buen aporte, me ayudó bastante
ResponderEliminarme ayudo a despejar mis dudas (Y)
ResponderEliminartengo el siguiente problema: ejecuto un webservice desde ajax, sin embargo aun que tenga la opcion async:true, sigue esperando la respuesta de ajax y no permite ejecutar otra instrucción (ni navegar) hasta que la anterior se termine :( que solución puedo darle? gracias.
ResponderEliminar