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