Hacker News Reader

Comment by sinatra | Hacker News Reader

We're considering using API Gateway and Lambda for our upcoming API service. Would love to hear feedback from anyone who's tried it. From the linked article, I got one gist [1] which wasn't very favorable for the API Gateway + Lambda setup.

[1] https://gist.githubusercontent.com/mpdehaan/d979252b9c69cfd1...

View on HN

I'm so glad you asked this! I just built a service on API Gateway + Lambda in the past two weeks. Here's my unstructured thoughts -

* I love that I don't have to provision any resources. The fact it will scale to volume automatically is a huge win.

* Lambda was a treat to work with. We used it with Python. Both the web console and API interface worked great for us.

* I was able to get Lambda development working end-to-end with a Makefile and the AWS CLI.

* API Gateway was a bear to work with. The concepts are unintuitive, the interface sucks, and the logging is lackluster. I found it difficult to go through the develop/test/deploy cycle on because of these issues.

* API Gateway is brand new. Brand new AWS services have bugs. We hit bugs.

* API Gateway documentation is awful.

* API Gateway had a bug where it stopped logging. If it doesn't log, it is literally impossible to debug. This hard-stopped development for 5 days while they worked on a fix.

* There's an invisible error case where your API doesn't have permissions to invoke the Lambda command. It's easy to hit and annoying.

* API Gateway doesn't support POST requests in the way you would expect. This leads to over-complicated setups for simple use cases.

* I really don't prefer the way mapping templates work in API Gateway.

Overall, our setup is humming along nicely, but it's just 2 routes. I just reviewed the Gist and I agree with many of the concerns expressed in it.

Have you reported any of your issues with the API Gateway to us? Please feel free to send them to me via the contact address in my HN profile and I will share them with the team ASAP!

I went through official support channels with my blocking issues. They have since been resolved.

This is such a great comment (polite, constructive, unbiased). It made me think that I wish there was a site like Ars Technica, but for PaaS/IaaS.

We have encountered consistently HTTP 500 response when creating multiple methods simultaneously. I think they have fixed it by now, but imagine the color of my face when I'm about to present a demo to a pretty large audience and we discover this bug?

I could have just written this comment -- I spent the past two weeks doing the same thing, but in JS, and hit all of the same problems. In the end, I think API Gateway is more trouble than it's worth. I wish Lambda could have an exposed HTTP endpoint. Mapping all of the arguments in and out is so incredibly tedious when developing and things are changing fast.

There's a lot of configuration. Using APIs keys takes like 25 steps. And I haven't really figured out a non really complicated way of creating a session between a web front-end and the API. And uploading code changes is a real PITA. But after that it just works.

As I've been programming an Alex backend I haven't really run into the cold start issues.

I have to admit this sort of Dashboard Driven Programming is quite alien, but there are benefits.

Depends on your use case and what language you are currently using. We are using nodejs and have built our own collection of libraries: https://github.com/MitocGroup/deep-framework

And here is an example: https://github.com/MitocGroup/deep-microservices-todo-app

Based on our experience, currently AWS Lambda is amazing for data / content / asset management use cases. Cold start is a known issue, which I hope AWS will solve sooner rather than later, because a lot of customers are complaining about it ;)

How is the 0.10.x version of Node treating you? That's what's keeping me off of Lambda at the moment. I guess I could use Babel before deployment, but what about external libs?

I'm thinking of the following workflow:

1. Write/debug with TypeScript -> ES6 on Node 5

2. Compile to a single file (not sure if I can use tsc or Babel for this -- basically just inline all the imports)

3. Transpile the resulting single file to ES5

I'm not sure if it's going to work, though...

I'll be honest, performance is not the best one :) That's why for the time being, we're using a combination of Lambda with ECS. Please don't quote me on that, but I have a feeling that by the time we're building the work-arounds, mine and your problems will be solved by the services ;)

Here is a practical approach, how we do it:

1. We write everything in ES6, following code styling from Airbnb - https://github.com/MitocGroup/javascript

2. Every Lambda is separate npm package, therefore npm is managing all the dependencies; We include node_modules folder into the .zip file and upload it to AWS

3. Using Babel, transpile ES6 to ES5 - https://github.com/MitocGroup/deep-microservices-todo-app/bl...

4. To support 0.10.x, we're requiring Babel Polyfill - https://github.com/MitocGroup/deep-microservices-todo-app/bl...

As anticipated, the performance is not the best one, but functional for some of our use cases where time is not a constrain. That's why the combination with Amazon ECS is perfect complimentary match when AWS Lambda doesn't perform well, as required by the application.

Thanks so much for posting this! I was really curious and found this to be helpful.

Yes, cold start (the delay you experience when your code hasn't been used in a while) is a big issue - it means serious additional latency which makes Lambda difficult to use for end-user facing applications. You can get around this by calling the code periodically .. but that defeats the purpose. There are also restrictions around how long your code can run. BUT, if your use case fits within these constraints, it's pretty cool to just deploy your code and forget about all of the administration hassles associated with running it on a server.

My company is building exclusively[0] on Lambda and API Gateway. It's definitely got its warts and you'll be paying an early adopters tax for sure.

My cofounder wrote a tool to help manage Lambda deployments: https://github.com/garnaat/kappa/tree/python-refactor

[0] Well as much as we can. We're building a Slack bot right now so we still need a container running under ECS to maintain the connection to Slack.

Reply on news.ycombinator.com