Tras el lanzamiento de AWS Lambda, realmente no había forma de invocar estas funciones de Lambda a través de una API HTTP a menos que estuviera enganchado a un Amazon API Gateway.

Por lo tanto, su arquitectura de AWS habría sido algo así:

Figure: An API powered using AWS Lambda consumed using API Gateway

Al utilizar esta puerta de enlace de API, en última instancia proporcionaba un punto de entrada a sus API internas (funciones de Lambda) que ayudaban a generar las respuestas necesarias para que sus aplicaciones funcionaran.

Pero, desde 2022, AWS introdujo las URL de función para las funciones de AWS Lambda. Esto significa que sus funciones Lambda pueden recibir un punto de enlace HTTP único (asignado por AWS) que permite invocar su función Lambda a través de la web, sin necesidad de configuración. De este modo, tu arquitectura se parecería a esto:

Figure: An API being invoked using a Function URL

Como puede ver, ya no tiene una API Gateway. En su lugar, su aplicación invoca directamente la función Lambda a través de una configuración CORS válida.

Por lo tanto, esto crea la pregunta,

¿qué debe utilizar en 2024? ¿Debería seguir utilizando Amazon API Gateway o debería utilizar URL de función?

Recuerda que si tu quieres aprender AWS te dejo link al CURSO

¿Qué es Amazon API Gateway?


Amazon API Gateway es un servicio totalmente administrado que le permite crear, publicar, mantener, monitorizar y proteger API HTTP y Websocket a cualquier escala.

En pocas palabras, una API Gateway actúa como "puerta de entrada" a todos los recursos internos de su sistema, como su lógica empresarial, datos o funcionalidad.

Por ejemplo, así es como funcionaría una pasarela de API típica:

Figure: The workings of Amazon API Gateway

Si aprovisiona una API Gateway, primero generará una URL de escenario para usted. Sería algo parecido a esto: 

https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/

Sus usuarios pueden utilizar esta URL de etapa para acceder a su API a través del enrutamiento basado en recursos. Por ejemplo, puede tener un recurso:

Tu recurso está indicado por la ruta - /users. Cuando un usuario invoque la ruta /users, accederá al recurso GetUsersLambda y obtendrá la lista de usuarios de la tabla Users.

Por lo tanto, su API Gateway actuará como punto de entrada a todos los recursos de su sistema.

De este modo, podrá gestionar de forma centralizada el modo en que se accede a sus recursos internos.

Pero esto no termina aquí. El uso de una API Gateway crea tiene más ventajas.

  1. Puedes aprovechar los mecanismos de autenticación y autorización en su aplicación utilizando IAM, API Key, Lambda y Cognito Authorizers.
  2. Puedes crear claves de API para diferentes consumidores de su API para una autenticación segura.
  3. Puedes crear un dominio personalizado para su API. Por ejemplo, puede optar por evitar el uso de la URL predeterminada de API Gateway y asignar algo como - https://api.myapp.com.
  4. Puedes aprovechar el almacenamiento en caché a nivel de puerta de enlace de API para almacenar en caché las respuestas servidas con frecuencia a fin de reducir la carga de sus recursos internos.
  5. Puedes aprovechar medidas de seguridad como la limitación de velocidad e incluso evitar ataques DOS mediante integraciones de AWS WAF.

Así que, con todo esto en mente, tiene sentido optar por una API Gateway ¿no? Pero, ¿por qué AWS introduce las URL de función?

¿Qué es una URL de función?


Una URL de función es un punto de enlace HTTP invocable que se vincula a una función Lambda que permite a los usuarios invocarla.

Puede crear y configurar una URL de función a través de la consola de Lambda o de la API de Lambda. Al crear una URL de función, Lambda genera automáticamente un punto final de URL único.

Una vez creada una URL de función, su punto final de URL nunca cambia. Los puntos finales de URL de función tienen el siguiente formato:

https://<url-id>.lambda-url.<region>.on.aws

De este modo, ya no tendrá una "puerta de entrada" a su API, sino que tratará la URL de la función como el punto de entrada a su servicio. Esto se parece a esto:

Este enfoque es más sencillo y fácil de usar. No sólo eso, sino que el uso de URL de función tiene más ventajas:

No tienes que pagar por servicios adicionales. Por ejemplo, con API Gateway, tienes que asumir el coste de API Gateway y de la función Lambda, mientras que con las URL de función, solo pagas por el uso de Lambda.


No está limitado al tiempo máximo de espera de 29 segundos de API Gateway. En su lugar, puede mantener una función Lambda en ejecución durante el tiempo de espera máximo de Lambda (15 minutos).


Tiene la opción de utilizar IAM Auth para proteger su función Lambda.
Pero, ¿cuándo utilizaría una URL de función?

Pasarela API frente a URL de función


He creado un resumen de las principales diferencias entre ambas:

Ahora, basándonos en estas diferencias, es bastante evidente que una URL de función es un enfoque más sencillo para exponer un punto final HTTP a su API.

Pero lo que esto significa es que, por lo general, no deberías utilizar una URL de función si estás creando una API de nivel empresarial que requiera funciones como almacenamiento en caché, limitación de velocidad y autorización compleja a través de Cogntio.

Sin embargo, si sólo se centra en lo siguiente:

  1. Construir un sitio web de renderizado del lado del servidor
  2. Un servicio que requiere un sondeo largo de más de 29 segundos.
  3. Quieres crear una invocación para un webhook.
  4. Quieres crear un único servicio simple, como un manejador de formularios.

Estos cuatro candidatos son perfectos para una URL de función. Pero, si está creando una solución que tiene flujos de autorización complejos, una nueva seguridad más estricta o si los tiempos de respuesta no superan los 29 segundos, utilice una pasarela de API para tener más control.

Creación de una aplicación sencilla con una URL de función


Ahora que tenemos una comprensión de la URL de función, vamos a echar un vistazo a cómo podemos implementar un controlador de formulario simple usando una URL de función.

Para ello, vamos a crear un simple formulario React junto con una función Lambda para manejar los eventos de envío al formulario.

Ahora, una cosa a entender aquí es que cuando estás construyendo una solución completa de extremo a extremo, estarás compartiendo entidades.

Por lo tanto, es importante que aproveches una herramienta que haga que el intercambio de entidades entre tus componentes frontend y backend sea más simple. Por lo tanto, voy a utilizar Bit para construir esta solución.

Si no está familiarizado con Bit, Bit es un sistema de compilación de nueva generación para software componible. Permite diseñar, desarrollar, construir, probar y versionar componentes en un espacio aislado. Es capaz de realizar un seguimiento de los usos de los componentes y propagar los cambios en un árbol de componentes utilizando su servidor CI.

Figure: A sample component managed using Bit

Por ejemplo, en la figura mostrada anteriormente, Bit es capaz de realizar un seguimiento de todos los componentes que se están utilizando en el árbol y actualizar todo el árbol si uno de los componentes sufre un cambio.

Así que, en nuestro caso, vamos a crear lo siguiente:

  1. Una Función Lambda
  2. Un Formulario

Para ello, vamos a centrarnos en el formulario Bits and Pieces Form Submission for Writers. Este formulario en sí está desarrollado y mantenido usando Bit:

Figure: Dependency tree of Bits and Pieces Submission Form

Como puedes ver, tiene:

  1. Un formulario React
  2. Una Entidad Compartida
  3. Una Lambda Function Handler
  4. Una React App que consume el formulario.

Así que ni siquiera necesitas crear tu solución desde cero. Primero, vamos a crear un espacio de trabajo Bit usando el comando:

bit init

A continuación, coge una copia de este código y hazlo tuyo utilizando el comando:

bit fork bits-and-pieces.article-submission/entities/article-submission-scheme && bit fork bits-and-pieces.article-submission/forms/article-submission-form && bit fork bits-and-pieces.article-submission/handlers/form-submission-handler && bit fork bits-and-pieces.article-submission/article-submission-app

Si has hecho esto con éxito, deberías ver la salida:

Figure: Forking the Components Sucessfully

A continuación, ejecuta el comando:

bit install --add-missing-deps

Esto instalará cualquier dependencia que falte para su espacio de trabajo Bit y mostrará el resultado:

Figure: Installing the Missing Dependencies

A continuación, inicie su servidor Bit utilizando el comando:

bit start

Verás la salida:

Figure: Launching the Bit Server

A continuación, puede empezar a adaptar el código a sus necesidades actualizando cada componente:

Figure: Viewing the Code

A continuación, una vez realizados los cambios, puede exportarlos a su propio ámbito de bits.

Un Bit Scope es donde viven tus componentes.

Después, puedes configurar las variables de entorno de Ripple CI para asignar una Clave de Acceso AWS y una Clave de Acceso Secreta para asegurar que tu función Lambda se despliega en AWS. Además, también tendrás que añadir una variable de entorno para un Token de Netlify para publicar tu app en Netlify.

Conclusión


Las URL de función son una buena opción para operaciones sencillas, mientras que las puertas de enlace de API deben utilizarse para gestionar API complejas que requieren una seguridad integral y mucho más.

Este artículo presenta una comparación en profundidad entre los dos, mientras que proporciona consejos sobre la selección del enfoque correcto.

Para resumir, utilice una URL de función si está:

  1. Construyendo un sitio web de renderizado del lado del servidor
  2. Un servicio que requiere un sondeo largo de más de 29 segundos.
  3. Creando una invocación para un webhook.
  4. Creando un servicio simple

Y, utilice una pasarela de API si está:

  1. Aprovechando mecanismos de autenticación y autorización en tu app utilizando IAM, API Key, Lambda y Cognito Authorizers.
  2. Crear claves de API para diferentes consumidores de su API para una autenticación segura.
  3. Creación de un dominio personalizado para su API.
  4. Aprovechar el almacenamiento en caché.
  5. Aprovechar las medidas de seguridad como la limitación de velocidad e incluso prevenir ataques DOS a través de integraciones AWS WAF.

Espero que hayas encontrado este artículo útil.

Gracias por leerlo.

Fuente