SCscarface74·May 25, 2020
What about writing CF to begin with for all your Lambda functions and setting up all their permissions to work alongside whatever other resources you have?
There are no “all of your lambda functions” with the proxy integration. You write your standard Node/Express, C#/WebAPI, Python/Flask API as you normally would and add two or three lines of code that translates the lambda event to the form your framework expects. I’ve seen similar proxy handlers for PHP, and Ruby. I am sure there is one for Java.
As far as setting up your permissions, you would have to create the same roles regardless and attach them to your EC2 instance or Fargate definition.
But as far the CF template. Here you go:
https://github.com/awslabs/aws-serverless-express/blob/maste...
Just make sure your build artifacts end up in the path specified by the CodeUri and chang
Read the rest
e your runtime to match your language. I’ve used this same template for JS, C#, and Python.
Nobody said anything about Docker or Fargate. This has nothing to do with the topic. My problems had no need for using Docker. Do you randomly pick a tool kit and just hope it works out? I suspect you're not really working at scale and costs aren't a concern.
You’re using your standard framework that you would usually use. You can use whatever deployment pipeline just as easily to deploy to EC2 with no code changes.
Great job. We are all proud of you I guess, but this is not how engineering works, especially when you're building at scale.
Actually it is. Since you are using a standard framework choose whatever deployment target you want....
Have you looked into Express and what dependencies it has, or do you just randomly pick the new framework of the week? I don't mean this as an attack, but I'm more than slightly annoyed that you keep referring to Node and Express, when that has nothing to do with the problems I'm trying to solve.
I also mentioned C# and Python. But as far as Java/Spring. Here you go.
https://github.com/awslabs/aws-serverless-java-container/wik...
The funny thing is you've written out all these lengthy posts but never stopped to ask about whatever constraints the system has. You started with the solution and are basically now looking at one of my constraints (JVM ecosystem) and are saying it's not a good choice.
I’ve also just posted a Java solution. The constraints of Lambda are well known and separate from Java - 15 minute runtime, limited CPU/Memory options and a 512MB limit of local TMP storage.
In the real world, we often don't have the ability to randomly swap out a language. There's enough properly tested code that already exists or a massive code base that entire teams are supporting. They're not going to drop that just so they can go pick up a shiny new framework or product offering. LOL.
My suggestion didn’t require “switching out the language”. Proxy integration works with every supported language - including Java. It also works with languages like PHP that are not supported via custom runtimes and third party open source solutions.