Nice. You have discovered two thirds of what Java’s Spring Framework has been doing since 2007 =)
What you might want to add is a Repository layer, that should help with some of the mentioned cons such as mocking/testability. There’s plenty of articles out there on the Controller-Service-Repository pattern
Good to see the Go ecosystem is maturing and taking over the sensible parts of the enterprise-y software that came before.
I think the difference here is that the Go standard library offers just an HTTP server interface and database interface and the Go ecosystem has created modular bits and bobs for particular functionality that you can choose to include, rather than having a single “framework” to work within. If you want a repository pattern, you can back it with handrolled SQL, use Sqlc.dev for semi-automatic generation from SQL, use Gorm for a traditional ORM, or Ent for a FaceBook graph-y ORM, etc. etc. There’s not a single blessed way to do it, which has both pros and cons.
Nice. You have discovered two thirds of what Java’s Spring Framework has been doing since 2007 =)
What you might want to add is a Repository layer, that should help with some of the mentioned cons such as mocking/testability. There’s plenty of articles out there on the Controller-Service-Repository pattern
Good to see the Go ecosystem is maturing and taking over the sensible parts of the enterprise-y software that came before.
I think the difference here is that the Go standard library offers just an HTTP server interface and database interface and the Go ecosystem has created modular bits and bobs for particular functionality that you can choose to include, rather than having a single “framework” to work within. If you want a repository pattern, you can back it with handrolled SQL, use Sqlc.dev for semi-automatic generation from SQL, use Gorm for a traditional ORM, or Ent for a FaceBook graph-y ORM, etc. etc. There’s not a single blessed way to do it, which has both pros and cons.