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