| Just my two cents how we do it in most of our projects at this point (~70 services in Go): >routing, middleware ogen (OpenAPI code generator), or a similar library >database connections from Go's stdlib mostly >an ORM sqlx (a lightweight wrapper around Go's stdlib which allows to hydrate results into structs) >authentication, sessions homegrown stuff, due to existing complex legacy stuff >job queues RabbitMQ's official Go wrapper (rabbitmq/amqp091-go) >email sending we delegate to a few separate VMs which already have postfix installed (and have good reputation) >dependency injection manual construction, works fine if split correctly >logging sirupsen/logrus (structured logger) >view template rendering React >metrics official Go wrappers for Prometheus Some of this stuff is already IMHO industry-standard (the default libs people reach to). To streamline creation of new services, we have a tool which can scaffold your project with all these dependencies already set up. |
All of the time you spent on building your scaffolding tool, researching on the libraries, checking and updating their version regularly; all of that isn’t necessary with a full-stack framework.
Once more: I’m not dismissing Go, or your way to set up projects, I’m just surprised someone would make the comparison to the Go std lib, which is so obviously not on the same level of integration and battery inclusion.