[raydiatian]

This was an interesting read, I’m currently facing a similar set of decisions. Good on you guys for finding an approach you’re excited to write about!

Throwing my two cents into the conversation, perhaps one day we’ll be able to have our cake and eat it too: If http://localstack.cloud (replicate AWS services locally) ever makes it to a 1.0 release, I may strongly think about vendor lock-in friendly approach like this. Unfortunately localstack recently (v0.14.1) forced me to give up on each ambition in my ideal develop-n-test-it-locally wishlist: first I gave up on a CDK provisioning resources locally, then I abandoned using ECR images for localstack lambda, and then I abandoned localstack altogether. Their S3 mock still works for local dev though!

The other thing is... if you want to develop locally but still on top of lambda, you either skip the api gateway altogether, or you write an undeployed shim for like expressJS or node http to fake that restful pattern locally. As great as not using APIGW+lambda-integration is, Lambda doesn’t believe in return codes other than 200 (ignoring throws and server failures), and you should probably use the AWS-sdk/client-lambda package. This all scatters weird lambda anti patterns. Yuck, that’s gonna be a big “chore:” commit if you ever get sufficiently sick of it. And I’m actually not in favor of using the lambda response interface, but APIGW lambda integrations are a seeming sht show. VTL and selection pattern seem so bad I’d rather just have more Kubernetes experience. Knative is good these days, I hear.

[rmbyrro]

Also abandoned localstack, most parts of it are hardly reliable.

Using SAM Local [1] to emulate API GW + Lambda and DynamoDB Local [2]. For the rest we have flags we can switch to either call the real deal on a personal AWS account, or mock responses locally.

[raydiatian]

If you get ambitious and download the source code, the integration tests make it exceeding evident as to why this is there case. Or rather more the lack of integration tests. But it’s hardly a knock against the localstack guys. AWS is a huge surface to cover. I’d love to see AWS absorb the project and release us something official. But that seems unlikely.

[bearjaws]

Localstack is a total mess, cryptic errors, it either works flawless or with lots of bugs.

I definitely like the idea of using AWS services as much as possible, unfortunately each dev getting their own account was shut down by my current employer.

[raydiatian]

I found the state of their documentation absolutely unacceptable. They also do blatantly misleading advertising stuff. They’ve got a huge list of “supported features” which either was once true or is an intentional misrepresentation. And they boast a “slack community with 10k+ users!” Although that may be technically true, in reality there are probably less than a dozen active users.

[WhyNotHugo]

I've worked with API servers that moved from a dedicated service to lambdas. We were using Django in this case, and just added a tiny wrapper that converts lambda>asgi (using Magum).

For local development, we continued using Django normally inside its own docker container with matching dependency versions and like.

[raydiatian]

Yeah I considered doing something like this but ultimately balked (maybe it was my inner prima dona) at the idea of needing to support undeployed adapter code (outside of Docker containers or build scripts), even if rarely. Might be easier with Python and Django, but the best typescript solutions I could come up required me to diverge from “normal-looking” express.js

[WhyNotHugo]

There is no undeployed adapter here. I use Django which exposes an asgi interface.

Traditionally, one would use something like Daphne as an HTTP<>asgi adapter. In my case, I use Magnum as a Lambda<>asgi adapter.

For development, I just use Django's build-in development server (which auto-reloads on code changes and alike).

So there's not "extra" code that's only used for development, and I really don't maintain any extra glue code myself either.