top | item 40562444

AWS Chalice

55 points| jacky2wong | 1 year ago |github.com

33 comments

order

danfritz|1 year ago

tedmiston|1 year ago

Not a huge surprise. It filled a weird niche, which was very easy to use for basic use cases, but Chalice only supported a small subset of Lambda features and didn't get much attention from AWS either.

As soon as you tried to do slightly more than was possible with it, it become unviable to manage all of the Lambdas and you end up having to use Terraform or similar anyway. If I were doing lots of new Lambdas today, I'd probably just use a third-party Terraform module for all of it.

tedivm|1 year ago

Yup! I used to use it, but was very disappointed in how little support it got and ended up dropping it. It's a great idea but never got enough resources to take off.

walthamstow|1 year ago

My last company were huge users of this. It's quite limited in terms of the resources it can deploy. To add additional resources that it doesn't work with, you need to write some Terraform.

I summarised the pattern we were using here https://github.com/elgrove/terroir

I'm not surprised the project is dead. AWS want everyone using the CDK for Python or CloudFormation

kapilvt|1 year ago

as a previous contributor and user, I would not recommend.

as a project in the GitHub aws organization, it can not accept non amazon external maintainers.

as a project, it has a single maintainer, doing on average, an hr every few months.

as a result of both of those , its not able to keep up, or reach critical mass on community.

it has fallen fairly far behind current lambda feature set. for a simple throw away, its okay, but if you want to grow something or take advantage of new features in the underlying service capabilities or integrations, this is a dead end.

I filed this ticket a few years ago https://github.com/aws/chalice/issues/2067

anonymousDan|1 year ago

Anyone here actually developing Python apps on AWS Lambda? If so do you use Serverless Framework or something else? I am part of a research project that is developing techniques for identifying security vulnerabilities in serverless apps so would be interested to understand what people are actually using for deployment and why.

tedmiston|1 year ago

If you try to use serverless (the framework) for Python, you very quickly learn that its support is a second-class citizen vs building in TS/JS.

Adjacent concern but: It also makes for unholy large Docker images to combine an entire JS toolchain with an entire Python toolchain.

Zappa is a better (more native) choice.

Terraform modules provide a decent Python Lambda experience.

AWS also has multiple semi-overlapping projects in the space. Chalice, SAM, and Powertools specifically to name a few. CDK more generally as well.

jbmsf|1 year ago

We deploy lambda using container images. We configure lambdas using terraform and deploy using GitHub actions.

We never considered using serverless or anything else because we also have ECS services, RDS databases, React frontends, and a lot more. It requires some knowhow to get a good setup, but it's hard to imagine anyone more opinionated framework doing what we want.

threecheese|1 year ago

We’re using a FastAPI stack, plus or minus Mangum, to selectively deploy to Fargate or Lambda depending on the workload requirements. Deploy using Terraform, ECS tasks just expose the local uwsgi and Lambda/Mangum just wraps the app entry point. It’s simple and lets us keep the codebases/libraries consistent.

FlyingAvatar|1 year ago

I switched from Chalice to Zappa several years ago and now manage several production projects with it.

ZiiS|1 year ago

CDK; don't love it, but it works.

Locutus_|1 year ago

I've built a couple of systems for customers using this, and the development comfort and Flask-like-ness is quite nice.

But it's really just completely dead by now, which is a bummer as this leaves a large complexity gap between this and jumping ahead to just doing full Lambda+CDK/Serverless/Terraform setups.

remram|1 year ago

How does that work? That code works partly at deploy time, to register the serverless app with SQS/..., and then it runs partly in the serverless invocation?

fabiofzero|1 year ago

Everyone in Quebec goes CÂLISSE DE TABARNAK

madamelic|1 year ago

Spin something up in an hour; spend a week fixing it when the magic inevitably breaks.

Maybe I am just incredibly jaded but I can't stand all these shortcut frameworks. It just ends up locking you into an ecosystem, especially AWS, and decouples you from building technical understanding of the system where if you go down the path long enough, you have no abort button besides an entire re-build because your code is enmeshed with the framework.

Do it right the first time: build it simple & iterate as you go. You don't need to be thinking about scaling to 1M concurrent users when you have 0 users.

poshmosh|1 year ago

Every framework have worked on for the last 12 years has bugs, breaks in certain situations. Every system in fact, i have worked on in 12 years has bugs and breaks. That is just the nature of software development.

You should be using frameworks instead of trying to reinvent things. It takes away decision fatigue and makes it easier for most teams to follow conventions that are already established.

boole1854|1 year ago

Hilariously, "chalice" is a strong swear word in Quebec French, so there the name of this product is roughly equivalent to "AWS Fuck".

https://en.wikipedia.org/wiki/Quebec_French_profanity

abtinf|1 year ago

What a bizarre phenomenon.

Per that article, the word chalice does mean chalice, but is treated as a swear word precisely because it doesn’t have any profane association and has sacred overtones?

How then would one discuss these topics at all? Is this an attempt to wipe out all the words entirely?

m1ck|1 year ago

I think the name is in reference to the Python Flask framework.

u32480932048|1 year ago

I think that was the codename for their billing module.

1123581321|1 year ago

If I'm reading right, you also giggle and roll your eyes whenever you're asked to connect to a host.