Hacker News Reader

> I can't imagine providing a feature-rich web application in Lambda without this kind of abstraction.

This reminded me of a caveat about using some of these abstractions – which is that they are still subject to the limits and restrictions of the underlying platform.

We discovered this the hard way once when an automatically generated function name or something was over the limit in prod (this issue [1] describes a similar problem). We did not catch this in dev because "dev" is one character under "prod" and our autogenerated name in dev hadn't put us over the limit. That was an interesting exercise in leaky abstractions.

[1] https://github.com/serverless/serverless/issues/2856

Yeah, missing the proxy pass option will definitely burn a prospective Lambda user.

I also felt a similar tinge when the post talks about KCL. Yes, you use it, and yes there are rules about output streams - but they all make sense when deployed in fairly complex environments. I can’t remember when I last used stdout for logging outside of greenfield development. Once it’s on prod everything goes to stderr and is highly structured.

Similar sentiments about Cognito. At some point of complexity you must have a server in between using the Admin* range of commands. If you want their “get going quickly” then yes, there are trade offs like WebViews. That said; I’ve never used Auth0 - so insert a Luddite warning here.

Finally, one hundred percent agree on CF.

Another pretty basic Lambda thing the author didn’t mention is the alias feature. So rather than having users-api-dev, users-api-qa - we just have users-api and it has a alias for each environment. The environment variable management is not amazing but just using a key-value JSON {dev: {a: “bc”}} works fine.

There’s also truly no reason one lambda function can’t have a collection of APIs (using the proxy method from API gateway). It’s literally no different from any other micro service setup. You can pick any abstraction for a function to cover.

If you start trying to work around the limits of your abstraction, maybe you just chose the wrong one in the first place.

This is what seems to happen when working with Lambda for me.

Could you elaborate on the proxy pass option piece?

https://docs.aws.amazon.com/apigateway/latest/developerguide...

From the article:

In Lambda proxy integration, when a client submits an API request, API Gateway passes to the integrated Lambda function the raw request as-is.

...and:

You can set up a Lambda proxy integration for any API method. But a Lambda proxy integration is more potent when it is configured for an API method involving a generic proxy resource. The generic proxy resource can be denoted by a special templated path variable of {proxy+}, the catch-all ANY method placeholder, or both.

> Not knowing that such tooling exists, or explicitly choosing not to use such tooling, and experiencing pain as a result seems to be common theme in this article. If you dive into architecting a system using AWS's product offerings without understanding the tradeoffs you're making, you will experience greater cost and greater friction -- hands down.

Which I think is one of the underlying points of the article.

> Many a startup has fallen prey to ElastiCache. It usually happens when the team is under-staffed and rushing for a deadline and they type in Redis into the AWS console:

I think this is a good article in the sense of "these are things that may or will bite you if you've not put a bit of thought into them".

Even the replies on this story upstream hint at that, with people debating Redis' durability, based on this:

> It’s best to design your system assuming that redis may or may not lose whatever is inside.

completely ignoring the follow up:

> Clustering or HA via Sentinel, can all come later when you know you need it!

It's like the first sentence was read and people leaped to the keyboard to reply passionately.

The API Gateway v2 HTTP stuff makes this even easier[0]. I switched some old services over from the v1 stuff (using '{proxy}' routes) to the v2 API and I was a lot happier. I especially like that v2 has an option for Auto-deploy. I'm sure the manual deployment stuff is really useful to some people but for my little projects it was a real pain to have to remember to trigger a new deployment any time I mad a change.

[0]: https://aws.amazon.com/blogs/compute/announcing-http-apis-fo...