Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Encore – Go framework for building distributed systems

github.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Show HN: Encore – Go framework for building distributed systems

#31

Post by skrtskrt »

Philip-J-Fry wrote: post #25
eandre wrote: post #2

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…

What is your setup for distributed tracing?

Re: Show HN: Encore – Go framework for building distributed systems

#33

Post by hnarn »

I'm sure this is awesome but do we really need phrases like "state of the art developer experience" giving you "unmatched productivity"? Is this the new normal? Do people feel the need to add this type of crazy hyperbole to stand out? I'm sure most people who read this are technical enough to appreciate this framework for what it can achieve technically, there's no need for an open source framework presentation to use the same language as a brochure for selling a sports car.

Re: Show HN: Encore – Go framework for building distributed systems

#34

Post by wdb »

skrtskrt wrote: post #31
Philip-J-Fry wrote: post #25

Earlier quoted context omitted.

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…

What is your setup for distributed tracing?

Personally, I am using Opentelemetry to create and export my distributed traces. At first sight it looks like they have reinvented the wheel for this project.

Re: Show HN: Encore – Go framework for building distributed systems

#35

Post by Philip-J-Fry »

skrtskrt wrote: post #31
Philip-J-Fry wrote: post #25

Earlier quoted context omitted.

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…

What is your setup for distributed tracing?

Elastic APM. As far as I am aware it's an implementation of the OpenTracing specification.

We just use the Elastic client libraries. Tell it where our APM server is, do the little bit of application set up and then view all our application traces in Kibana.

All applications follow the same basic setup. Probably less than 20 lines of code and then wrapping some HTTP handlers and HTTP clients. Then we have some application specific spans.

Re: Show HN: Encore – Go framework for building distributed systems

#36

Post by void_mint »

It looks like the secret management is just pulling env variables into a map? Maybe it's a language thing but this isn't really how I interpret people describing the need for "secrets management", which is more to do with secure storage and access control. A map of key/values pulled from the environment doesn't really handle any of that, right?

Re: Show HN: Encore – Go framework for building distributed systems

#37

Post by thwarted »

hnarn wrote: post #33

I'm sure this is awesome but do we really need phrases like "state of the art developer experience" giving you "unmatched productivity"? Is this the new normal? Do people feel the need to add this type of crazy hyperbole to stand out? I'm sure most people who read this are technical enough to appreciate this framework for what it can achieve technically, there's no need for an open source framework presentation to us…

This has escalated from the claims of being "simple" and "fun to use", and a bunch of other highly subjective, and distracting, terms.

Re: Show HN: Encore – Go framework for building distributed systems

#38

Post by kbar13 »

Philip-J-Fry wrote: post #25
eandre wrote: post #2

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…

isnt code generation just smarter copypasta? since there will be no difference in complexity during runtime i feel like it's equivalent, just maybe more powerful

what i mean is that you have complexity in your existing setup too... its just that you understand the ins and outs. and so the same applies to encore.

Re: Show HN: Encore – Go framework for building distributed systems

#39

Post by dastx »

dhagz wrote: post #9

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…

One thing I absolute hate about magic in code is that it's often done at runtime. Considering the idiomatic way for go is actually have code generated and checked into git makes a huge difference.

Re: Show HN: Encore – Go framework for building distributed systems

#40

Post by eandre »

void_mint wrote: post #36

It looks like the secret management is just pulling env variables into a map? Maybe it's a language thing but this isn't really how I interpret people describing the need for "secrets management", which is more to do with secure storage and access control. A map of key/values pulled from the environment doesn't really handle any of that, right?

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