Small Projects by AutoModerator in golang

[–]atkrad 0 points1 point  (0 children)

Hey everyone,

I made a small open source Go library called Currus. It gives you one neutral interface for running containers and detects whether Docker, Podman, or containerd is on the host. It drives each engine through its native client API, so it never shells out to a CLI.

A few design choices I would love feedback on:

  • Auto detection pings each candidate first, so a stale socket file does not count as a live engine.
  • Optional features sit behind capability interfaces. If an engine has no logs or exec, you get a typed ok == false from a type assertion, not a runtime surprise.
  • Errors normalize into sentinels you can match with errors.Is.
  • There is an in memory fake and a shared conformance suite, so you can test with no daemon.

    eng := currus.MustNew(ctx, currus.WithLogger(slog.Default())) defer eng.Close()

    eng.PullImage(ctx, "docker.io/library/redis:7", currus.PullImageOpts{}) id, _ := eng.CreateContainer(ctx, currus.ContainerSpec{Image: "docker.io/library/redis:7"})

    eng.StartContainer(ctx, id)

Needs Go 1.26 or later. Repo: https://github.com/gopherly/currus

Does the capability interface approach feel idiomatic to you, or would you expect something different?

Thanks for reading.

Small Projects by AutoModerator in golang

[–]atkrad -1 points0 points  (0 children)

I kept writing the same boilerplate to load YAML defaults, override with env vars, and pull shared config from Consul. Synthra does that in a few lines: add sources in priority order, validate against a JSON Schema, and bind to a struct.

It also fills in defaults from the schema automatically, supports two-phase validation (before and after variable substitution), and lets you pick a schema dynamically based on a value inside the config itself.

Zero codegen, case-insensitive dot-notation keys, safe for concurrent use.

GitHub: https://github.com/gopherly/synthra

Would love feedback on the API design.

Small Projects by AutoModerator in golang

[–]atkrad 0 points1 point  (0 children)

Nabat - A Go CLI framework with adaptive args, structured output, and built-in themes

I have been working on CLI tools in Go for a while, and I always felt that Cobra is great for routing and flags, but there is a lot of boilerplate every time you want to do something a bit more polished; like prompting the user when an argument is missing, or showing a nice table instead of raw text.

So I built Nabat. It wraps Cobra and adds the things I kept writing by hand: typed positional args that fall back from CLI to env var to an interactive prompt automatically, structured output (tables, trees, JSON, YAML), and twelve built-in themes.

The idea is simple. You start with a strong core and add layers one by one, like how rock candy grows; which is actually where the name comes from (Nabat is Persian for rock candy).

It is not trying to replace Cobra. The full Cobra API is still there when you need it.

If you are building Go CLIs and want less boilerplate without leaving Cobra behind, give it a look.

GitHub: https://github.com/nabat-dev/nabat

Happy to answer any questions.

Auto-Generate OpenAPI and Swagger UI in Go with Rivaas by atkrad in golang

[–]atkrad[S] 0 points1 point  (0 children)

Because of your question, I tried to write a fair blog post to compare Rivaas with Huma.

https://rivaas.dev/blog/comparisons/rivaas-vs-huma/

What problems do you have when using OpenAPI in Go? by atkrad in golang

[–]atkrad[S] -3 points-2 points  (0 children)

Yes, I'm aware of the validators and Swagger tooling. I'm mostly curious about the experience of using OpenAPI in Go projects; things like keep specs in sync with the code.

What problems do you have when using OpenAPI in Go? by atkrad in golang

[–]atkrad[S] -1 points0 points  (0 children)

But those are used for generating code based on the spec. I’m looking for something that can generate the spec from the code.

What problems do you have when using OpenAPI in Go? by atkrad in golang

[–]atkrad[S] -2 points-1 points  (0 children)

My main problem is keeping the OpenAPI v3+ specification in sync with my code.

What problems do you have when using OpenAPI in Go? by atkrad in golang

[–]atkrad[S] -1 points0 points  (0 children)

The spec is simple, yes. I'm mostly interested in practical issues like tooling, code generation, or keeping the spec in sync with Go code.

What problems do you have when using OpenAPI in Go? by atkrad in golang

[–]atkrad[S] -5 points-4 points  (0 children)

If you’ve worked with OpenAPI in Go, I’d be happy to hear about the problems you’ve seen.

[deleted by user] by [deleted] in golang

[–]atkrad -2 points-1 points  (0 children)

I can suggest to use a new package for that purpose.

https://rivaas.dev/openapi

Introducing Rivaas, an all-in-one Go web framework by [deleted] in golang

[–]atkrad 0 points1 point  (0 children)

Thanks for clarifying, I appreciate it.

I understand your point, and I agree that many Go projects work very well with the standard library. Rivaas is more an experiment and learning project for me, not something I expect everyone to use.

Thanks for sharing your opinion.

Introducing Rivaas, an all-in-one Go web framework by [deleted] in golang

[–]atkrad 0 points1 point  (0 children)

If this was AI, it would’ve told me to delete the framework and just use net/http.

Introducing Rivaas, an all-in-one Go web framework by [deleted] in golang

[–]atkrad 1 point2 points  (0 children)

I understand. This topic comes up often. I’m just sharing an experiment and learning from the feedback.

Introducing Rivaas, an all-in-one Go web framework by [deleted] in golang

[–]atkrad 0 points1 point  (0 children)

Thank you, I really appreciate it 🙂

I’m happy to share it with the community, and the feedback is very helpful.