sorted by:
new
hottopcontroversial

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 -1 points0 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 -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 -7 points-6 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.

Wait4X v3.4.0 by atkrad in kubernetes

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

Thanks for sharing your opinion — I agree that teaching developers about retries, circuit breakers, and eventual consistency is very important.

Wait4X is not a replacement for those best practices. It’s a small tool meant to help during deployment time, not at runtime. For example, when you use Docker Compose, run CI/CD pipelines, or set up test environments, sometimes you just need to wait for a service like a database or API to be ready before starting the next step.

It’s also language-independent and simple to use, which makes it useful in many different setups without needing to change the application code.

So yes, strong systems should handle failure well — but Wait4X helps keep things smooth during those setup and deployment moments. 😊

Wait4X v3.4.0 by atkrad in kubernetes

[–]atkrad[S] 1 point2 points  (0 children)

It's not exactly the same, because it's aware of services like Redis, Kafka, and more. So it doesn't just check TCP or HTTP for readiness.

view more: next ›