However, I have to admit that my first reaction to that difficulty in getting the account ID from the path/query/etc would have been to just shove it in the request body JSON that was already coming through. Then it could probably be taken out of the path completely, which would be a win for url privacy at least. This doesn't seem like the showstopper that the auth issue does.
Last Sunday morning, I was so excited to move my APIs over to AWS’s API Gateway. That evening, I was ready to kill.
I spent the entire day (9+ hrs) getting merely two API routes working. A GET and a dreaded POST request.
I couldn’t tell from your post if you eventually figured it out, but it is possible to get the POST request body and url params in your Lambda event as JSON.
In my POST Method’s Integration Request, here’s how I get the query string parameter and the request body. I use this Input Mapping.
#set($inputRoot = $input.path('$'))
"name" : "$inputRoot.name",
“email” : "$inputRoot.email”
A “glass half full” way to think about all of this is that the AWS API Gateway is ridiculously strict about what data can be passed in to your Lambda functions, and you must explicitly state that data.
Here are other problems I ran into over the weekend:
- The web console is super buggy with broken links and really, really bad UX.
- The documentation is missing for many essential components.
- No support for API Gateway in the AWS SDKs
- I can't figure out how to copy resource methods, so I have to do tons of redundant manual input when creating each resource method, which includes explicitly stating every HTTP Error response code.
- Returning error objects from Lambda functions also needs mapping.
- Out-of-the-box slow response times. My Lambda function with two simple DynamoDB queries often takes 3 seconds to return a result when its route is hit.
Overall, I'm a huge AWS fanboy but the execution of this product is incomplete and out of touch.
C'mon AWS, you can pull through on this. Keep it simple. Build out from there. We all want you to succeed.
1. We are updating the documentation in response to the feedback in this thread and in the blog post. Additional feedback is always welcome.
2. Based on the feedback in the blog post, mappings can now access the JSON body of a POST. See the answer (login required) at https://forums.aws.amazon.com/thread.jspa?messageID=645596&#... .
3. Models are not required for validation. They are simply used to generate the objects in the client SDKs.
I’ll update my original posts so that they do not misinform others and I look forward to future improvements.
One additional thing that would be incredibly useful is a simple blog post that describes steps/options one could take to increase API Gateway + Lambda response times. I'm fiddling with this now, but I wish I had some guidance as to where to focus my optimizations and how to make them, all in one place and straight from the source (AWS). For example, I'd love some examples on API Gateway caching, making my API accessible in multiple regions, how to make my Lambda functions faster, and why my first requests to my API Gateway + Lambda routes are so slow even after only a few minutes of inactivity. On a first request, my Lambda function will run for 1.2 seconds but the network request as a whole takes 2.8-3.2 seconds, yet every immediate subsequent request comes in much faster (~1.4 seconds)(Everything is in the same us-east region). If there is nothing I can do about this because the server my lambda function is on has been de-prioritized due to minutes of inactivity and is in an idle state, then the guide on optimizing elsewhere is even more necessary. This is the last piece of the story that is missing for me personally, and it causes me to hesitate before deploying more code. Also, if you have this written already and I've missed it, please let me know!
Overall, you've lowered the barriers to entry and increased efficiency so much I plan on deploying much more server side code than ever before.
- Execution response time: the responses to API > Lambda > DynamoDB are too slow
- Reference Samples: we need docs and/or code samples with the most common patterns and workflows for mBaaS and IoT (i.e: user authentication with JWT and ACLs via the API > Lambda > Dynamo)
Many of us are stoked about this product. Hope you can iron out the issues that the community is raising and that are preventing wider adoption. The concept of server-less microservices via REST looks like the next big trend after containers. Hope you get it just right soon... I plan to make intensive use of this service in no time! =)
I'm also using API Gateway + Lambda + DynamoDB
All of them are very slow on first request, even the DynamoDB queries. After that, they're much quicker, unless there are maybe 5 mins of inactivity.
A good, useful, detailed blogpost that highlights a number of important blocker-level issues - and there's an unexpected, speedy response from the previously-anonymous devs announcing improvements as a result of the post and analysis itself.
Your section about authentication resounds with me loud and clear, I couldn't hack it out in 6 hours. This will be a pain point for anyone using API Gateway for anything other than a toy API.
Technically, stretching the system a bit, one could argue that we don't need backend software running on EC2 anymore, since everything can be a Lambda function with an associated HTTP endpoint to trigger it. I have been thinking about this a lot, and it could work if being locked into AWS is considered an acceptable risk.
For anything else more API-oriented (more authentication schemes, better security, more logging options, etc) I would suggest checking out Kong (https://github.com/Mashape/kong), which is pluggable with extra functionality and can work in front of the AWS API Gateway to enhance the REST-to-Lambda interface (and with any other API).
This is a huge risk. If they shut you out, for whatever reason, you're done. You can't port your code to somewhere else. It's Lambda specific.
is that really true tho? Its just a function that does work from a request and send the result off to some where else.
To make a future port easier, the functions could also be modularized by keeping the real business logic and the Lambda integration separate, but integrated.
We have a client who is looking at sending a massive amount of data to a REST API. Looks like we are going back to Elastic Beanstalk, which is pretty good, it just has servers. But it works.
And, I'd say that using Dyanamo as a DB locks you much more securely into AWS than API Gateway and Lambda. Be pretty easy to take those Lambda functions and map them back into Express or Restify routes. Changing the database, arg.
If you create a lambda function and add a gateway inside the lambda function configuration screen, it will give you a bad API gateway URL. Going into the API gateway page and looking at your stages URL and trying that works.
This just proves that it was rushed out. I do like the idea though and want to use it, but I don't think it'll be ready until Q4.
This is something I've also noticed. Even their official examples are really slow 
About auth: I've been researching API Gateway + Lambda and auth via Amazon Cognito. As of now the best example for auth I've found is LambdAuth . I'm trying to add the API Gateway in the mix, it looks possible to integrate it.
I also agree that docs and more explicit examples are needed.
Turns out to retrieve JSON you can use $input.json().
Full details are on the AWS documentation page. Not sure if this has been newly added as I only found it today.
If anyone is interested in an open-source version of Amazon API / Amazon Lamba, you can check out: http://github.com/bigcompany/hook.io http://hook.io
Google App Engine and Heroku and Azure also have lock-in too, to varying degrees -- but at the start it still makes sense to use these sorts of services rather than worry about lock-in. (And if someone later gives you $100k of compute credits on their platform, and it costs you less than that to rewrite the "lock-in" parts, then you still win.)
With no upfront costs and w/o the need to manage servers I'd say it's actually the other way around! ;)