21–30 of 71 posts
Earlier quoted context omitted.
It's like gRPC in the sense that it's endpoint-centric rather than URL-centric.
At least for a public facing API i would like some more customization possibilities, but this can maybe be done with a seperate BFF / API Gateway / GraphQL gateway etc. Thanks for the answer.
This looks neat, but man. I'm not a fan of code generation magic. It's part of the reason I moved away from the Rails ecosystem - even though I knew what Rails was doing under the hood, the magic started to give me the heebie-jeebies. Maybe I'm weird, but I'd rather spend 10-15 minutes writing some boilerplate for a service and control the code than trust a third-party tool to do it for me. I also feel like this is d…
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 im…
We built a conference management system using an early release of Encore this past winter, and it was an amazing experience. I can absolutely recommend you check it out if you're building services in Go. The developer experience is so WELL thought out, it's a pleasure to use it.
Looks pretty cool! Couple of questions: - Is there a story behind the name? - Out of curiosity, does “Encore Cloud” also run on AWS? - I think a lot of developers have a mentality of “rather write boilerplate than be tied to a platform not endorsed by $bigCompany”. Do you have a strategy to mitigate this?
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).
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.…
We have everything like CI/CD, distributed tracing and one line project generation.
It's just based on some foundation code and some simple bash scripts to find and replace some service specific things.
And then it's just the basic routing and HTTP handlers to unmarshal and marshal responses.
When all your services are built off the same foundation then creating a new one is pretty much and copy and paste job in my experience.
It's a cool project but it seems like unnecessary complexity, something I strive to avoid.
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.…
I've built my fair share of Go microservices and have never felt the need to develop an entire framework like this. We have everything like CI/CD, distributed tracing and one line project generation. It's just based on some foundation code and some simple bash scripts to find and replace some service specific things. And then it's just the basic routing and HTTP handlers to unmarshal and marshal responses. When all y…
- 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 :)
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.…
You mentioned on another comment that you would like to introduce a pub/sub element to this. Could you talk a bit more about that? I can see how that work for communicating between services managed by Encore but could it be integrated with existing event sources?
In general, I guess it's hard to see how some of this would integrate with existing systems nicely. If you're starting from a blank slate I'm sure the devex is excellent, but what would the workflow be like if only a small percentage of my infrastructure was done this way? (Which is how I imagine all of your customers would start out).
I like how go-kit's transport not just JSON and HTTP (e.g. gRPC and protobufs are supported).