thecupisblue4 days ago
9x faster than express is a bold claim, would be interesting to see how it holds up with real application logic and some real benchmarks/usecases.
As for the language support; we support Go and TypeScript today. We're focusing on making these rock-solid first, but more languages are on the roadmap. Python is the likely next candidate.
If I really cared about that I would just use k8s instead of hoping an infra as code tool mapped all these services somehow.
For example, your code references "a Postgres database" and Encore provisions Cloud SQL on GCP or RDS on AWS, handling the provider-specific config automatically. The cloud-specific details stay out of your application code.
And if you prefer Kubernetes, we can provision and configure GKE or EKS instead of serverless compute. The point is your application code stays the same regardless.
In practice, that is not really viable and should not be a motivating factor when choosing technologies.
It’s like having a in-house 24/7 dev ops infra team but for a fraction of the cost!
Disclaimer: Our infrastructure needs are not super complex: Web services, SQL, key-value store, pub-sub and few other parts, your mileage may vary depending on your needs.
1. I want to deploy to a testing environment where I may want to use different users, different sized services, or even mock services so I don't have to pay for them? 2. I want to develop in an isolated environment (maybe without internet or simply I'm trying to develop a narrow feature that doesn't require the rest of the infrastructure)? 3. How does it handle security elements like VPCs, IAM roles, all these things that are the context my application runs in that I don't necessarily want to couple to my application code?
2. The `encore run` command automatically starts local emulators for your infrastructure and starts the app as a single binary.
3. Encore uses static analysis to determine not only what infrastructure is used, but also what uses it. Based on these requirements we provision relevant VPCs, subnets, IAM Roles, SQL users, Security Groups etc. using best practices for each cloud provider. The specifics depend on how you configure each environment, and you can inspect all provisioned resources in your cloud console (and require approval for new cost-bearing infrastructure, and so on and so forth)
The goal is to start with good defaults so you don't have to think about every config detail upfront, but nothing is locked down. You can also set up approval workflows for any infrastructure changes that have cost implications before they're applied.
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
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).
btw, on a tangent, I always thought that infra can be defined in typescript types.... is is strange but no need for custom language
someone please steal this idea and make something out of it
``` interface BaseEC2 extends AWSEC2 { type: '...' }
// export means build export interface MyInstance extends BaseEC2 { // some customisations }
// fleet export interface EC2Fleet extends EC2Fleet { instances: MyInstance } ```
etc...
wacky idea but I kind of like it
Encore Cloud (optional managed platform) has a generous free tier and paid plans for production teams that want automatic infrastructure provisioning in their own AWS/GCP accounts. You can find more details at encore.cloud/pricing
Please, improve the support, we would love to pay if you guys were responsive enough.
That being said, I know we are expensive and "don't add to bottom line" so this looks like good enough hacky kludge as anything else.