rayterrill.com

A place to share technical learnings, etc.

View My GitHub Profile

aws | jekyll | github | apigateway | serverless | ad | powershell | windows | webdev | nodejs | terraform | consul | nomad | jenkins | traefik | azuread | azure | nextjs |

24 January 2019

Choosing a Framework to Deploy Lambda and API Gateway Apps

At our org, we’re pushing hard into converting some of our existing applications to utilize serverless technologies, and specifically Lambda + API Gateway. While we normally use Terraform to deploy our infrastructure into AWS, the amount of code required to get Lambda + API Gateway integrations deployed was really a showstopper for us - just absolutely brutal. So we embarked on looking at a number of tools to see if we could find a better way.

ClaudiaJS

We initially looked at ClaudiaJS, due to it’s reputation for being very simple to get started. We were excited to get a few things deploy pretty quickly using the proxyAPI functionality, but quickly ran into issues where we needed to go out and make manual changes to the deployed code in AWS after-the-face because of limitations in that model (specifically things like requiring api keys, etc). We pivoted to the claudia-api-builder model, but ended up running into limitations there as well.

Pros:

Cons:

Serverless Framework

After running into the issues with ClaudiaJS, we pivoted our efforts over to Serverless Framework. As with ClaudiaJS, we were able to pretty quickly get things deployed using the examples. We also were able to get some more advanced things going with a little trial and error. At this point, we’ve been able to deploy our code to PROD, and we have not encountered any insurmountable issues.

Pros:

Cons:

Conclusion

In the end, we’ve elected to move forward with Serverless Framework, as it appears to support the most options going forward, but still is relatively simple to bootstrap new developers onto the framework.

tags: aws - apigateway - serverless