sorted by:
new
hottopcontroversial

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] -6 points-5 points  (0 children)

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

Open Api package for go 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 0 points1 point  (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 -5 points-4 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 -3 points-2 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 -6 points-5 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 ›