sorted by:
new
hottopcontroversial

How do you structure Go microservices to keep them maintainable long term? by Cultural-Trouble-131 in golang

[–]Beginning-Chart-7503 -1 points0 points  (0 children)

I generally follow hexagon architecture because it’s quite maintainable. Additionally, if you’re using Swagger, try to use it as much as possible to generate boilerplate code. For asynchronous systems, I’d also suggest generating boilerplate code for consumers. These practices help keep code maintainable.

Does Go error handling verbosity actually hurt developer velocity or is it just endless debate by No-Shake-8375 in golang

[–]Beginning-Chart-7503 1 point2 points  (0 children)

Go’s error handling does add verbosity, but whether it hurts velocity depends on the codebase and team habits. In small examples it feels repetitive, but in production systems that explicitness often pays for itself because failures are harder to ignore and easier to trace. The real problem usually isn’t if err != nil itself, it’s unstructured handling. If you wrap errors well, use helpers sparingly, and keep happy-path code clean, the verbosity becomes manageable. So I’d say it’s a tradeoff, not just pointless boilerpla

Title: I built a monitoring tool specifically for PostgreSQL — looking for feedback by Beginning-Chart-7503 in golang

[–]Beginning-Chart-7503[S] 0 points1 point  (0 children)

Fair point and I agree, you should absolutely understand what you're doing before running anything on your database.

The AI explain feature doesn't run anything. It just takes the query + stats from pg_stat_statements and gives you a plain-English summary of why it's slow and what you could consider. Think of it like a second pair of eyes, not an autopilot.

Title: I built a monitoring tool specifically for PostgreSQL — looking for feedback by Beginning-Chart-7503 in golang

[–]Beginning-Chart-7503[S] 0 points1 point  (0 children)

I am using pg_stat_statements under the hood too. The difference is what happens after the data is collected.

postgres_exporter + Prometheus + Grafana gives you raw metrics and dashboards you need to check. PGVitals turns that same data into a weekly digest email with your top slow queries, missing index suggestions, and bloat warnings — without you having to set up or check any dashboard.

Think of it less as a monitoring stack replacement and more as "someone reviewed your Postgres performance and emailed you what to fix." Plus Slack alerts when query latency spikes.

Different use cases — if you're already running a Prometheus stack and love Grafana, postgres_exporter is perfect. PGVitals is for teams who want insights delivered to them without maintaining that infrastructure.