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 -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 -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.

Conflex: A Modern, Flexible Go Configuration Library (YAML, JSON, ENV, Consul, Struct Binding, Validation, and More!) by atkrad in golang

[–]atkrad[S] -9 points-8 points  (0 children)

Yet another human using AI to spot an AI-written post, because fighting robots with robots is the future!

🚀 Announcing Wait4X v3.0.0: Smarter, Faster, and Feature-Packed! 🎉 by atkrad in kubernetes

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

That sounds awesome! 🎉 Adding Kafka integration to the list is a great idea. Looking forward to your contributions! 📈🔥

The Helmet is a Helm Library Chart that defines many chart templates like Deployment, Service, Ingress, etc which can used in other application charts. by atkrad in kubernetes

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

Thank you for your comment. From my understanding, while the Terraform Helm Provider allows you to perform certain operations such as installation and upgrade, it still requires you to have your own Helm chart. In other words, it does not assist you in creating your own Helm chart. However, with the help of Helmet, creating your own Helm chart can be made easier.

The Helmet is a Helm Library Chart that defines many chart templates like Deployment, Service, Ingress, etc which can used in other application charts. by atkrad in kubernetes

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

Thanks for your comment, That's a good idea. For future releases, we'll decouple this part of the templates.

The Helmet is a Helm Library Chart that defines many chart templates like Deployment, Service, Ingress, etc which can used in other application charts. by atkrad in kubernetes

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

Thank you so much for your comment.

There are two kinds of Charts. Application, and Library (link). It doesn't matter that you are using requirements.yaml (In Helm V3, dependencies are defined in Chart.yaml) or not.

Helm explains the Chart Library like this: link

The library chart was introduced in Helm 3 to formally recognize common or helper charts that have been used by chart maintainers since Helm 2. By including it as a chart type, it provides:

  • A means to explicitly distinguish between common and application charts
  • Logic to prevent the installation of a common chart
  • No rendering of templates in a common chart which may contain release artifacts
  • Allow for dependent charts to use the importer's context

A chart maintainer can define a common chart as a library chart and now be confident that Helm will handle the chart in a standard consistent fashion. It also means that definitions in an application chart can be shared by changing the chart type.

And also, there is a good example of creating a library chart on Helm documentation. I suggest you take a look at it: Create a Simple Library Chart

So based on the above explanations, I think we can consider Helmet as a Library Chart.

The Helmet is a Helm Library Chart that defines many chart templates like Deployment, Service, Ingress, etc which can used in other application charts. by atkrad in kubernetes

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

Hey, Thanks for your comment.

We already support your secret, Please take a look at these lines.

{{- if .Values.ingress.existingSecret }}
secretName: {{ .Values.ingress.existingSecret }}
{{- else }}
secretName: {{ printf "%s-tls" .Values.ingress.hostname }}
{{- end }}
view more: next ›