Mientras estaba leyendo acerca de permisos y volteando de cabeza el feature mas complicado de mi proyecto hasta el momento, me encontré con unos tips de unos artículos de Google Cloud, que me parecieron super importantes de interiorizar.
Si desean leerlo directo de Google y en inglés, se los dejo en las referencias; yo aquí haré un resumen con unos cuantos ejemplos.
HTTP vs Serverless Functions
Usualmente cuando ya sabemos hacer APIs, esto lo tenemos clarísimo:
- GET -> Listas/Obtienes entidades (SELECT en SQL)
- POST -> Creas entidades (INSERT en SQL)
- PUT/PATCH -> Actualizas entidades (UPDATE en SQL)
- DELETE -> Eliminas entidades (DELETE en SQL)
Y nos podemos llegar a sentir confiados en la mayoría de casos; ya que las llamadas están sobre el protocolo TCP/TLS.
Todo ocurre síncrono, funciona o no funciona, el cliente tiene conexión a Internet o no; en otras palabras.. se llega a la lógica de la función como máximo una vez.
En cambio cuando hablamos de webhooks, queues y otros tipos de comunicaciones asíncronas, se podría llegar a la lógica de la función al menos una vez, el que trata de comunicarse trata de asegurarse que sus clientes hallan recibido la información e intenta múltiples veces.
Es como si fuera el casero buscando que pagues, no va a parar hasta haber intentado como 20 veces y luego irán los policías a revocarte para que dejes de consumir recursos.
Resilient y Reliable
Estas palabras se refieren a la capacidad que tiene una función de ser confiable, manejar casos de error. Estas características son muy importantes al trabajar con funciones asíncronas y todas dependientes de eventos en la nube.
Irónicamente, no se suelen colocar en el código, se configuran y siempre se deben contemplar.
Idempotent
Considerando el concepto anterior, digamos que tenemos una función que es "resilent" y "reliable" encargada de hacer webscrapping, descargando imágenes a múltiples storages en la nube.
- El evento se ejecuta una primera vez, se descarga la primera imagen, luego la segunda no logró descargarse.
- El evento reintenta ejecutándose una segunda vez, se descarga otra vez la primera imagen, y finalmente descarga la segunda.
El resultado seria la primera imagen descargada 2 veces y la segunda solo 1 vez.
Una solución a esto sería el manejo de event IDs (como Google Cloud soporta), simples ids o incluso utilizar una funcion por cada componente, KISS "keep it simple and short" ...
Referencias
