Hacker News Reader

Comment by Philip-J-Fry | Hacker News Reader

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 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.

View on HN

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 :)

> it seems like unnecessary complexity, something I strive to avoid.

This. Adding complexity to reduce boilerplate seems like the wrong direction to go in (pun intended).

I like boilerplate. I can overwrite it with special cases whenever I need to, and it takes up very little mental space (as opposed to the rules needed to generate it).

I hated working in Rails because of all the magic. I love working in Go because of the lack of magic.

But y'know. I'm sure it'll suit someone. Good luck with it OP.

Curious - how do you end up handling transactions that span services?

I'm getting into go, but there doesn't seem to be a great pattern for this. Used to @Transactional on the service, so feels annoying in having to build that.

I think the answers requires more context, but for example one well known pattern is called “sagas” for implementing long lived distributed transactions.

The gist is you timeout but provide a way for transactions to resume.

Also obviously there’s 2PC but again it depends on what unite trying to solve.

How does @Transactional span services? With a JtaTransaction manager?

If you are saying about micro services here which talk grpc/http then @Transactional does not help.

If you are talking about inside one service then you have write all that boilerplates, and it will not look as simple as Java

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.

No it isn't.

If you did down enough, you'll find some form of code generation in your environment of choice. If nothing else, compilers, but it's not limited to them.

The largest difference between that and copypasta is - generated code can be easily updated, by regenerating it.

It's also an implementation detail. I've read elsewhere in this thread that code generation is bad and language supported features are good. I'm not sure it's so clear cut. It shouldn't matter if the generated code is mostly invisible (when it's baked inside your binary by the compiler, due to language support), versus code that is generated in the source language and then compiled.

One thing that's always bad is mixing generated and non-generated code. You have all the disadvantages and little benefit.

I don't think it is. It's fundamentally taking the code out of your control. With my services all the code is there, we can tweak it if necessary, we're not tied to a framework, it's just a barebones foundation of a Go application.

Nothing is hidden away from you with code generation. There's no in-between steps from what you write to what you execute other than Go compilation.

I think it's the wrong mentality to require a whole new set of third-party tools to maintain a Go application. It then starts feeling like you're writing Javascript, and does anyone really want that?

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.

Any plans to switch to Opentelemetry?

Not that I know of

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.

Reply on news.ycombinator.com