En esta loca mania que se me dio por escribir todo desde 0, una de las cosas que tenia pendiente era implementar un buscador para el blog. Convengamos que mi premisa es "gastar lo menos posible", asi que tener una instancia con un Elastic estaba un poco descartado. Estuve investigando un poco que me convenia usar, y termine eligiendo Algolia, principalmente porque el Free tier que proveen es mas que suficiente para un blog que no lee nadie 🤣

Como se puede ver en la imagen, es bastante generoso con los limites, asi que vamos por ese lado. Pero si ese no les copa, o tienen ganas de implementar otro, estos pasos aplican perfectamente.

Elegido el motor de busqueda, ahora viene la parte mas divertida: implementarlo!

Obviamente la opcion mas facil es simplemente llamar al endpoint de Algolia al momento de agregar, modificar o eliminar algun post. Pero para que tenemos sistemas desacoplados si no lo vamos a usar? Hagamoslo mas moderno y mas extensible!

AWS

Vamos a usar SQS para hacer el famoso decoupling. Definimos el nombre de la cola de SQS que vamos a usar. En mi caso, que toda la infra esta manejada con Pulumi, unicamente tuve que definir que queria usar una nueva SQS queue (comun, no hace falta que sea FIFO) y poner los permisos necesarios. Para nuestro ejemplo, vamos a llamarla sqs-search. Esta queue va a procesar todo (alta, baja y modificaciones) pero podria hacer una queue para cada "tipo".

API

Nuestra API de administracion no sufre ningun cambio. Nah, para, como haces para avisar que hay un mensaje nuevo? se preguntaran ustedes. Bueno, vamos a usar algo llamado DynamoDB Events. Se puede configurar la tabla DynamoDb para que genere un evento cada vez que un cambio ocurre, y que dispare otra funcion lambda cuando eso suceda. A la funcion le llega un evento del tipo Stream, que incluye el nuevo registro (o el registro actualizado y el anterior, en caso que te interese tener el antes y el despues). De esto se encarga AWS, nosotros solo configuramos (de nuevo, con Pulumi) que esa tabla va a tener una Lambda que se ejecuta cada vez que se cambia, agrega o borra un registro. De nuevo, hicimos de-couple: la API ni se entera de todo esto, no tiene conexion con la queue ni con el buscador.

Lambda Event: DynamoDb

Esta funcion Lambda recibe el registro (que puso la misma tabla DynamoDb), con todos los datos del post (titulo, descripcion, URL, etc etc). En mi caso, la estructura de tablas es super simple, asi que puedo recibir todos los atributos sin excederme, pero si tienen muchos datos, pueden solo mandar el ID y leer la info de nuevo para conseguir el registro completo.

Una vez recibido ese mensaje, que yo se de que tipo es (agregar, editar, borrar), puedo agregar el mensaje a la SQS Queue para que sea procesado.

SQS

En nuestra cola SQS, hay otra lambda function que esta escuchando cada vez que llega un mensaje. Apenas el lambda de DynamoDB agrega el mensaje a esta queue, se dispara el proceso, donde, finalmente, llamamos a la API de Algolia para agregar, modificar o eliminar el post del indice de busqueda.

Entonces, todo esto, queda mas o menos asi:

Lo bueno de esta arquitectura es que, digamos, si en el futuro quiero sacar Algolia y poner, no se, un Elasticsearch (matando una cucaracha con una bomba atomica, basicamente), solamente tengo que modificar la ultima parte: el resto del "camino" funciona perfecto, porque es agnostico 😁

Espero que les haya gustado y servido! Ya saben, cualquier duda me pueden escribir por Twitter a @peorth (ya implementare comentarios).