eandre

I grew tired of always looking up the magic invocation to add, remove, upgrade dependencies, so I assembled all the stuff you need to know to use Go modules effectively on a single page. Hopefully it's helpful to others!

It might be like rails in the sense of prioritizing the developer experience, but the goals are quite different. Rails is a web framework designed to build websites. Encore is a backend framework designed to build distributed systems. In practice that means the feature sets are extremely different, with very little overlap.

No, we do support storing secrets and securely delivering them to the running application. See `encore secret set --help`.

If that works for you, all the better! There are quite a few things that Encore does beyond what you mentioned:

- Automatically sets up dedicated Preview Environments for your Pull Requests

- Provisions all the infrastructure you need, both for local development as well as in production (and other environments like staging or testing)

- Provides auto-completion and compile-time type safety for making cross-service API calls, with a single line of code

- Integrates secrets management, API documentation, frontend client generation, etc :)

Good questions! "Encore Cloud" is currently deployed to AWS and DigitalOcean under the hood.

As for being tied to us, that's a big part of why we're open sourcing it. We see that Encore can rather reduce lock-in, as the code you end up writing with Encore is very cloud-agnostic, but also quite agnostic of Encore itself (by virtue of using static analysis, you end up writing mostly regular business logic).

And when you use it you can deploy the applications to your own account at any major cloud provider, so you can use your existing trust relationships with your cloud provider of choice.

As for the name, it's a bit of a wordplay :). "en-" for "to bring about [something]", and "core" for "the part of something that is central to its existence or character" (in our case backend development).

Fair enough :) We're working on adding GraphQL support as an alternative approach to exposing your API, and what you suggested wouldn't be that difficult to add either.

Since Encore supports deploying to your own cloud, it's definitely possible to integrate with existing systems you already have in place.

We're also working on expanding the set of infrastructure primitives supported, so that you get the Encore experience for doing more types of things. Things like Pub/Sub and message queues are the next things we'd like to add support for.

It's like gRPC in the sense that it's endpoint-centric rather than URL-centric.

Thanks for the feedback. I think there are many different types of magic. In my (biased) opinion I think the code generation we do is much more on the side of "how to do this is obvious but annoying" rather than on the "I don't know what's happening" side.

As for platform vs framework, my realization is that the traditional separation of frameworks/libraries from infrastructure means that it's almost impossible to improve many parts of the developer experience.

The annoying parts of building backends and distributed systems come from the integration between the two. Setting up databases, secrets, and so on all require bridging that gap. Another big area that we're investing in is providing insights about how your application works at runtime, in production, directly at your fingertips when you're writing code. That's also not something you can do without integrating across that gap.

As you pointed out in the edit, you can absolutely use Encore with your own cloud. We're working on making the deployment options much more flexible, but it's very much not another "let's make an infrastructure tool and then charge a premium on top of your cloud bill to manage it for you".

Our business model is much more about aligning the incentives with the developers. We want to provide the best developer experience out there, and by charging for that as opposed to for infrastructure, we'll happily invest time to reduce our users' and customers' cloud bills, rather than just selling them more servers they don't really need.

Thanks! Encore does support dropping down to plain HTTP requests which lets you use Websockets, see [1]. We hope to make it more ergonomic and less boilerplate-y in the future, but it is supported :)

[1] https://github.com/encoredev/examples/tree/main/websocket-ec...

Currently Encore deploys to Kubernetes, and uses Terraform under the hood to provision the infrastructure. Over time we'll add much more flexibility in how you deploy the application and the infrastructure we support.

It's not another infrastructure offering but rather a new developer experience for building backend applications and distributed systems. The idea is to get the developer feedback loop to be about building your product and writing business logic.

Encore then uses static analysis to understand what your application does, the different backend services involved, and the infrastructure you need. It can then provision all the infrastructure, servers, databases, and hook everything together.

A lot of the seminal research papers are surprisingly readable! I really recommend reading them to get a good feel for the sort of problems you face at scale and good ways of handling them.

Off the top of my head: a lot of stuff from Google (Dapper, Stubby, Zanzibar). Dynamo from Amazon. Leslie Lamport's guide on TLA+. The two generals problem, distributed consensus, and so on.

Most distributed systems don't need all that fancy stuff, but it's useful to know regardless. Even the simplest systems will get weird and interesting bottlenecks with scale.

And then a lot of just doing it in practice! Find a job at a startup with some scale, and learn on the job.

I've been working on Encore for the past 3 years.

I was at Spotify for the past 8 years as a Staff Software Engineer. We grew frustrated with the disproportionally large effort needed to build even simple backend applications, and created Encore to solve this problem.

Encore uses static analysis and code generation to reduce the boilerplate you have to write, resulting in an extremely productive developer experience. It's a combination of a framework that combines with a cloud platform in order to simplify all aspects of building distributed systems, from how you write code to shipping it to production.

I shared some more background on Encore here [1]. Feedback very much appreciated :)

[1] https://twitter.com/_eandre/status/1381668476662734849

Thanks! Yes, it's quite unlike other frameworks :). We also provide a complete cloud platform that provides things like CI/CD, secrets management, GitHub integration and more.

Yes, it analyzes your code and builds up a really detailed understanding of what your app does.

We use that analysis to do a bunch of stuff:

- Automatically provision cloud infrastructure

- Generate API Documentation and type-safe clients to easily call your API from a frontend

- Automatically instrument your application with Distributed Tracing

- And lots more planned :)

Hey HN, I've been working on this framework for the past 3 years because I grew frustrated with how slow it is to build backend applications.

Encore offers a different approach to backend development, heavily based on static analysis and code generation to simplify and improve the developer experience.

Among other things, it automatically instruments your app and adds Distributed Tracing, generates high-quality and interactive API Documentation, and lots more.

Would love your feedback :)

We use it as part of mTLS to provide access to application metadata. It doesn't need to be SPIFFE but it made sense for our use case :)

I don't disagree,but I think there's space for several levels of abstraction between where we are today and no-code tools.

TLS always felt like a scary beast to me until I started writing Go. The crypto/tls package is amazing and makes doing incredible things with TLS super easy. We're using it in lots of interesting ways behind the scenes for Encore, leveraging Vault, a custom CA, SPIFFE for workload identity and more.

I haven't read the book, but learning more about TLS is easily one of the best time investments I've made.

Agreed completely. Today there's such a large disconnect between how you think about software (APIs, services, systems, data flows, replication, data storage, access patterns, and so on) and how you actually develop software, with plain text files on disk that don't at all resemble our mental model.

I've been working on a new type of framework that is about making how we develop software match this mental model. Where the higher-level primitives we think in terms of are first-class citizens at the language level.

I think only then is it possible to reason about, and scale, software in a much more productive and effective way.

In the ideal case it should be constant and as close to zero as possible! Of course we don't live in that world for arbitrary scale, but surely "a one person SaaS" should be able to do without so much low-level tech and infrastructure work.

It seems to me that even when you outsource your infrastructure to a major cloud provider, you're still spending a lot of time yourself setting everything up.

I'm certainly not criticising Anthony here – what he's done, especially in terms of product development, is remarkable – but just thinking about the industry at large.

The most natural way is to join a startup that is scaling. You can of course learn by doing it yourself on the side, but in practice "learning by doing" on the job is by far the most effective in my experience.

I also hope we don't need to know all this stuff in the future. It's pretty really low-level and it's much better if we can focus more on creating differentiation and building your actual product. (Full disclosure: I've founded a startup that's trying to do exactly that, so I guess I'm biased!)

Super interesting! Definitely feels like a lot of fairly low-level tech to have to deal with for a one-person company, but I guess that doesn't surprise me any more :)

It seems to me that it should be possible to operate a public transit system profitably if you assume a steady state, meaning no need to expand. But when cities grow, public transit systems must continually expand to continue to service the population which requires massive amounts of up-front capital, which each takes decades to pay back through rider fees.

This submission comes at the perfect time. I've been working on improving the docs for Encore for the past week, and while I was aware of different types of documentation, this does an excellent job breaking it down and making it concrete.

For a long time I've felt there are a plethora of communities for frontend development, but little for backend development. Any recommendations on backend-oriented communities?

In my experience languages have a culture of their own.

For example, C++ has a culture of caring about low-level details to squeeze out maximum performance. I once found myself writing something that wasn't performance critical in C++ due to a library I needed, and just minutes later I caught myself reading up on move semantics for maximum efficiency. I couldn't help myself getting sucked in by the language culture!

Java's culture, in my opinion, is one of abstractions. There's little in the language to force you down that path, other than decades of it being the prevalent way Java is written, which bleeds into the standard library, core frameworks, and becomes the Java Way of Thinking.

I don't think they're the same, but I do think low-code has become synonymous with incredibly special-purpose tools that barely resemble programming.

We've been building Encore [1] to improve on this. It's a backend framework that simplifies not only how you write code, but also integrates with your cloud provider and automates the infrastructure management.

We're still early, so feedback appreciated!

[1] https://encore.dev

Awesome! I have lots of fond memories from the days of writing World of Warcraft addons (CTMod, CT_RaidAssist, ...). Great to see the community is still going.

Thanks, it's back up now.