When creating lambdas, the original thought was to create an api gateway/lambda endpoint for each function type (e.g. lcgen, hydrograph manipulator, eurotop, jpm, pst - essentially, 1 endpoint, 1 function) but during the course of conversation it's become apparent that A) more lambdas will need to be provisioned over time, which requires infra support each time, and B) this approach doesn't scale well, especially to multiple environments. @adamscarberry mentioned that we could potentially have a sort of router lambda, which we pass a parameter which determines which function we run. I wasn't a fan of this approach initially, bit I think considering the overhead needed to provision resources in the CWBI environment, it's not a bad idea, so I advocated for it.
If we went this route, @trietmnj's first thought was to consolidate lambda functions by module type (inundation, erosion, or riverine). This works well, but one thing we will run into in the future is that not all the scripts in use share the same runtime/language (they're not all python), so it's likely we may want to provision one lambda per runtime as opposed to module type.
Questions that need to be addressed before we go down this approach:
- Will each function require a fairly similar amount of memory? One lambda = one config.
When creating lambdas, the original thought was to create an api gateway/lambda endpoint for each function type (e.g. lcgen, hydrograph manipulator, eurotop, jpm, pst - essentially, 1 endpoint, 1 function) but during the course of conversation it's become apparent that A) more lambdas will need to be provisioned over time, which requires infra support each time, and B) this approach doesn't scale well, especially to multiple environments. @adamscarberry mentioned that we could potentially have a sort of router lambda, which we pass a parameter which determines which function we run. I wasn't a fan of this approach initially, bit I think considering the overhead needed to provision resources in the CWBI environment, it's not a bad idea, so I advocated for it.
If we went this route, @trietmnj's first thought was to consolidate lambda functions by module type (inundation, erosion, or riverine). This works well, but one thing we will run into in the future is that not all the scripts in use share the same runtime/language (they're not all python), so it's likely we may want to provision one lambda per runtime as opposed to module type.
Questions that need to be addressed before we go down this approach: