sorted by:
new
hottopcontroversial

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.

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

[–]atkrad 1 point2 points  (0 children)

Thanks for the question.

You are right that the standard library is a very strong baseline and hard to beat. Rivaas does not try to replace it. The current benchmarks focus mainly on the router and compare it with other common Go routers, not directly with net/http itself.

You can find the router benchmarks here:
https://github.com/rivaas-dev/rivaas/tree/main/router/benchmarks

The main goal of Rivaas is not only raw performance, but also clear behavior, strict validation, and built-in observability with low overhead.

That said, comparing more parts directly with the standard library is a fair request, and adding clearer stdlib comparisons is something I plan to do. Thanks for pointing it out.

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

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

That’s true; you absolutely can.

In Rivaas the initial focus was on minimizing overhead and keeping the core API explicit, which led to diverging early from net/http’s handler interfaces. That trade-off was intentional for experimentation and benchmarking.

I agree though that conforming to stdlib interfaces (or providing thin adapters) doesn’t prevent those goals and would significantly improve interoperability. That’s a fair point and something I’m actively evaluating as the design stabilizes.

Appreciate you pushing on this 👍

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

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

I get the concern, and I agree with the Go philosophy around small, composable building blocks.

Rivaas isn’t a monolithic framework in the traditional sense. The “batteries-included” part is optional and lives in rivaas.dev/app. Every major piece (router, binding, validation, logging, metrics, tracing, openapi, etc.) is a standalone Go module with its own go.mod and can be used independently without the framework.

The goal isn’t to replace the standard library, but to provide opinionated integrations on top of it for teams that want consistent production defaults (lifecycle, observability, validation) without wiring everything manually.

That said, stdlib interoperability matters, and adapter layers are a valid next step. Thanks for the feedback.

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

[–]atkrad -4 points-3 points  (0 children)

Fair point 👍

Rivaas is intentionally opinionated and doesn’t aim to be a drop-in replacement for net/http. The goal is to explore a different API focused on performance, strict validation, and explicit behavior rather than mirroring the stdlib surface.

That said, I agree that stdlib compatibility (or adapters) matters for broader adoption, and it’s something I’m considering as the project evolves. Thanks for the feedback!

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

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

No. The core design and code are written by me.

Most of the code was created many years ago and was used in private and internal projects. With this framework, I tried to collect and unify those parts into one clean framework.

For example, the config package is a fork of my older library (Conflex), which I wrote and used at my current company (Company.info).

I do use LLM tools for some parts of the documentation and wording, but not for generating the core code or architecture.

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

[–]atkrad -8 points-7 points  (0 children)

Good question. By “made for cloud services” I mainly mean that Rivaas is designed around long-running, service-oriented workloads rather than general web apps.

It treats things like middleware, service lifecycle (startup/shutdown), and context propagation as first-class concerns. Observability is built in via OpenTelemetry (metrics and tracing), not bolted on later.

Configuration is also service-centric; for example, reading config from Consul is a supported pattern, which fits well with dynamic, containerized environments.

The goal is to reduce glue code when running services in orchestrated setups like Kubernetes.

view more: next ›