This an interesting idea, but I'd be skeptical of having this much coupling between application code and infrastructure. It's like an anti-12 Factor App.
It might make sense for something like a "serverless" app where the units of the business logic are intended to map directly onto cloud provider entities.
I'd argue it's the opposite of coupling. Your application code references logical resources (database connection, pub/sub topic, bucket) without knowing anything about the underlying infrastructure. Encore extracts these needs and a configurable planner transforms them into actual infrastructure.
The same application code can run locally (Docker), on AWS (RDS, SQS, Lambda), or GCP (Cloud SQL, Pub/Sub, Cloud Run) without changes. That's less coupling than explicitly configuring cloud-specific resources in Terraform or even using cloud SDKs directly.
Re: Chalice - similar idea but Chalice is AWS-only and focused on serverless functions. Encore is cloud-agnostic and works for any backend architecture (monoliths, microservices, containers, functions).
But you're inverting the dependency-injection pattern (dependency-extraction?) rather than feeding your app the things it needs to run, you're encoding the dependencies directly into the application code. Maybe it works great in practice, I haven't tried it, but it looks brittle and hard to test.
It might make sense for something like a "serverless" app where the units of the business logic are intended to map directly onto cloud provider entities.
It reminds me of https://aws.github.io/chalice/ but cloud-agnostic and Typescript in place of Python