goyek VS provisioning-backend

You can also take a look at https://github.com/goyek/goyek. Personally I use either Make or goyek. Disclaimer: I am the author of goyek

I think that Make is so popular, because Go comes from C. Many C and C++ devs migrated to Go. Personally, I created goyek as an alternative.

how about https://github.com/goyek/goyek

It's also what I'm using currently as direct make/makefile replacement. What I plan to use next time though is goyek: https://github.com/goyek/goyek . Concept looks really nice but I haven't tried it yet in any real case scenario.

https://github.com/goyek/goyek v2.0.0 is to be released in two months. Now it is the best time to provide feedback.

In my "free time" I develop https://github.com/goyek/goyek

https://github.com/goyek/goyek (initially `taskflow`) first release was more than a year ago. So far been slightly improved.

Check out: https://github.com/goyek/goyek#make Also reusing Make targets between multiple repositories is harder (e.g. via git submodules) Here are some presentation if you are more interested: https://github.com/goyek/goyek#presentations

I wrote a makefile which installs tools into PROJDIR/bin which is also in the gitignore.

Extremely simple in go, you just implement what is called Doer interface (one method). Here is an example from one of my projects, it is a simple decorator with logger in this case. Then you just initialize the client with this instance, in my project it is slightly more complex because I also setup OpenTelemetry but you get the idea.

Authentication and authorization is typically just a middleware which is essentially a function. Recently I implemented a RBAC functionality into our microservice which does not use any big framework. On our platform we have a RBAC service we need to call via REST. As you can see the whole patch is small if you exclude the generated OpenAPI client.

We use DAO/DAL in our app and I ran into the same problem - DAO does not work well with transactions. We have our own WithTransaction function which is currently only used within one model and that works fine. But the problem appears when we want to do a transaction across several models - that needs to be done in the business (service) layer.

Our project does have extensive makefile broken down into individual files so it is more readable. As you can see, we have targets for database, code quality, modules, testing, client generation, OpenAPI etc. It also has a trivial help:

Here is our code: https://github.com/RHEnVision/provisioning-backend/tree/main/pkg/worker

Our solution is simply one Redis queue, jobs have "type" (string) and are marshalled via Gob (for type safety) and there is no return value from job or error. This makes things extremely easy. We keep statistics (metrics) of job queue size and "in flight" jobs. Here is our implementation, just for inspiration. I suggest to write this on your own: https://github.com/RHEnVision/provisioning-backend/tree/main/pkg/worker