¿Puedo escribir una función Lambda para manejar múltiples solicitudes de API REST? Tengo mis datos en Dynamo DB
Flujo: API Gateway-->Función Lambda-->Dynamo DB Ejemplo:
Request1:GET Method-Need to pull data from Table1 /device/{device_id}/start/{start_date}/end/{end_date}/events Request2:GET Method-Need to pull data from Table2 /device/{device_id}/start/{start_date}/end/{end_date}/event_count Request3:POST Method-Need to put data from Table3 /device/{device_id}/start/{start_date}/end/{end_date}/fault_events
¿Cuál es la mejor solución? ¿Debería escribir 3 funciones lambda diferentes para manejar 3 solicitudes diferentes o puedo manejar las 3 solicitudes en una función Lambda GRANDE?
Sí, puede tener una función Lambda que maneje más de una API. La pregunta es ¿por qué?
Hacer esto se considera (casi) un antipatrón, ya que no podrá escalar de forma independiente los distintos escenarios.
Estas son dos diapositivas del enlace pegado arriba de la charla de Chris Munns por fin re:invent y estoy totalmente de acuerdo.
Si bien no sé lo suficiente sobre su caso de uso para recomendar el uso de 1 o varios Lambda, puedo explicar una forma de trabajar con todas las consultas dentro de una función.
Puede pasar parámetros del evento lambda, que provienen de los parámetros de la API de AWS y luego usarlos para determinar la siguiente lógica. Un ejemplo se vería así:
def lambda_handler(event, context): try: type_query = str(event['queryStringParameters']['type_query']) if type_query == 'x': ...do the things elif type_query == 'y': ...do the other things elif type_query == 'z': ...do the 3rd thing except: return { 'body': "Invalid Params" }
¡Espero que esto ayude!
Debe encontrar el equilibrio adecuado en función de lo que hace su aplicación/servicio. En general, me gusta dividir las cosas en partes bastante pequeñas, pero debe tener cuidado de no ir demasiado lejos y crear nanoservicios, que muchos consideran un antipatrón debido a la sobrecarga de mantenimiento que termina creando .