provisioning-backend
gotaskr
provisioning-backend | gotaskr | |
---|---|---|
12 | 8 | |
13 | 17 | |
- | - | |
9.2 | 6.9 | |
5 days ago | 2 months ago | |
Go | Go | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
provisioning-backend
-
[Question] How do you guys separate your tooling for different version
I wrote a makefile which installs tools into PROJDIR/bin which is also in the gitignore.
-
Instrument a third party package
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.
-
Can you really build a complete restful service without any frameworks?
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.
- In-memory key value store
-
Repository with sqlc, how to hide transactions?
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.
-
Is your makefile supposed to be a justfile?
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:
-
Any references for open source mini workflow libraries or systems written in Go?
Here is our code: https://github.com/RHEnVision/provisioning-backend/tree/main/pkg/worker
- Want to know if this is a valid approach
- Cache headers when serving embedded files
-
When to use a queue library or straight redis?
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
gotaskr
-
Generic Task Runner in Go -> gotaskr
Feel free to head over to GitHub and check the wiki for more details and I would be happy to get feedback or improvement ideas for gotaskr.
-
Build / Makefile templates for Go monorepo?
I created https://github.com/Roemer/gotaskr for that and we are very happy with it for a very complex build system. Give it a try if you want.
-
Is your makefile supposed to be a justfile?
May I present my alternative https://github.com/Roemer/gotaskr It is kind of similar to magefile but provides some other features similar to cake build and inbuilt tools useful for devops. And also it is a plain go program so no magic compilation in the background. It replaced basically 100 bash files in our rather complex build/deploy setup. Sometimes a declarative approach is just not enough.
-
Unpopular opinion: CI/CD engines are an awful idea
I have used many CI systems on large scale and to be honest, Jenkins is still my favorite. Everything you need is provided and works. You have 100% control over the workflow. With code. All those declarative yaml based ones need sooooo much workarounds to get more complex workflows to run and often you are just stuck with a less optimal solution. Beside the build workflow, we do not write any build logic in the ci engine but use external code runners instead. For .Net I used Cake or Nuke build for example but now my absolute preference for build logic is go. There we use a task runner like gotaskr. This helps having the build logic centralized and usually you can also run different build tasks locally to debug and test them. Also with go, you don‘t need any runtime to run the logic. Just build the task runner once and then you can copy the binary anywhere (eg for parallel build tasks) and just run it. This is optimal to integrate it in Docker base builds so you don‘t need to change the base image at all.
-
Task runner like go-task/task, but in pure Go, no external DSLs
May I present my solution: https://github.com/Roemer/gotaskr Heavily inspired by cake build. It has no compile magic anywhere. Just write your go file and run the tasks in it. Or build it and re-use it in a ci for example.
-
Utility library, most gopher way for namespaces/packages
The current refactoring is in: https://github.com/Roemer/gotaskr/tree/feature/toolsrefactoring
-
Any open source projects need help ?
I'm a go youngling that tried to create a task runner (inspired by cake build for .net) in go as an alternative to magefile. What I would like is to get some feedback about how it is implemented and if there are go-principles that are violated and where the code should be improved. So if you want to do some reviewing, feel free to have a look at https://github.com/Roemer/gotaskr
What are some alternatives?
goyek - Task automation Go library
weaver - Programming framework for writing and deploying cloud applications.
spok - It's a build system Jim, but not as we know it 🖖
go-gitlab - GitLab Go SDK
kertish-dfs - Kertish-dfs is a simple distributed storage platform, implements file storage on a single distributed computer cluster, and provides interfaces for file/folder handling. Kertish-dfs aims primarily for completely distributed operation without a single point of failure, scalable to the exabyte level.
earthly - Super simple build framework with fast, repeatable builds and an instantly familiar syntax – like Dockerfile and Makefile had a baby.
devtron - Tool integration platform for Kubernetes
dejq - Very Simple Job Queue
ziti - The parent project for OpenZiti. Here you will find the executables for a fully zero trust, application embedded, programmable network @OpenZiti
mkdkr - mkdkr = Makefile + Docker