I love lambda's, but api gateway was far from mature the last time I used it (6 months ago).
Unless they have made serious updates to the deployment workflow, feature set, and documentation I would not recommend building your products on it.
Unless they have made serious updates to the deployment workflow, feature set, and documentation I would not recommend building your products on it.
If I would have to name one thing, it's that the configuration of API Gateway via the UI is unbearable if you have a nontrivial amount of routes (> 3). I need to configure Authorization, Error code mappings etc. for every route, although they are exactly the same. If there would be per-gateway defaults I can set with per-route overrides, that would cut down the setup time by 95%, which is the main thing holding me back from using API Gateway for projects that would suit it.
Right now the only option I seem to have is using a tool like Terraform to automate it, which is a pain to adopt if you already have a running API Gateway.
Still better than manual clicking in my opinion.
http://docs.aws.amazon.com/apigateway/api-reference/resource...
It gets you to hello lambda (python) in one shot, from the cli. Anything written down in one repo is going to be far more undertstandable than piles of hidden behaviors and obscure error messages. I think there's a new one on their blog for node.
But that workflow doesn't make sense for real dev teams. So there's https://github.com/serverless/serverless . It's driven by a yaml file and is intuitive.
The only thing I'm bothered by is lack of environment variables (have to hard code them) and terrible API Gateway latency - see https://news.ycombinator.com/item?id=12681926 further down the page
const config = require('./config.json');
Then you do config.secrets.apiKey etc
You have to gitignore config.json and include it in serverless.yml
Other languages might have to read and parse that JSON into one of their data structures.
Are they still requiring sn unrestricted iam profile? That is a non starter for most orgs.
Also, I found working with serverless to be pretty unintuitive. You are relying entirely on large config files and it was very difficult and time consuming for me to test and rollback several different configs.